Hm... sharpen yer virtual pencils

Post #61,063 by tseliot 11/4/02 5:44:17 PM Reply	Hm... sharpen yer virtual pencils Given: 1. That most programming is done to automate tasks, 2. Programming is a task and is often itself automated, and 3. This recursive automation is an ongoing process, Question: where are we right now today on this arc? I was talking to Todd about the desire of management to commoditize programmers as much as possible, which leads to the (empty) promises of Microsoft to do just that. We snickered into our seafood and moved on, but now I'm thinking more at length about it. Todd bemoaned how he wants to get out of coding web apps 'cause the tools have gone to hell. Could that be an indicator that, at least for designing web apps, the tech is getting pushed faster than the culture can bear, or is it instead an indication that perhaps, again for this subindustry, commoditization is really on the horizon? Extra credit question: where on this arc of automation is your particular subindustry? Are you about to be replaced by a machine? Is it the right/wrong time for that? And if you are about to be replaced, are you moving on to something else or are you starting a union? Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
Post #61,064 by drewk 11/4/02 6:03:05 PM Reply	Gave my opinion a while back Right [link\|/forums/render/content/show?contentid=41398\|here]. As for the extra credit, I and my co-workers are working very hard to try to obsolete ourselves. Problem is the problem scope grows faster than the tools we've completed. ie: By the time we complete a new aplication and roll it out, someone has realized three more things we can use it for and they want "just a little change". We spend 99% of our time on the applications and the rest on improving the tools we use for application development. Until someone (with control of the purse strings) sees the value of having people actually work on the tools, this isn't about to change. PS: Thankyou thankyou thankyou Scott for the search. === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #61,078 by tseliot 11/4/02 7:48:38 PM Reply	Shoot. Missed that whole conversation. Thanks for the link. Doug said (in the thread drewk referenced) All that happens in reality is that menial tasks get automated (computers aren't smart as much as fast). Robots are good at simple repetitive tasks. Good discussion but not quite what I'm getting at. I see a difference between, for example: A. A bunch of machinists who got replaced by a robot assembly line, and B. A bunch of programmers who got replaced by a bunch of non-programming users because their knowledge-domain got machine-codified into a tool. The difference is that in Situation A, the task might be said to be simple and repetitive. In Situation B, the task still requires a human; it's just that it doesn't require an engineer anymore. Sounds to me like you're nowhere near Situation B, me droog. Thanks for the input! :) BTW, what would you call your "subindustry"? Web apps? Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
Post #61,082 by boxley 11/4/02 7:58:12 PM Reply	My goal is to automate as much as possible then pass as many tasks to lesser paid knowledge folks, power users etc and move on. This is what managements mantra is and I agree with it, However how many sysadmins here can trace a circuit board and make needed repairs. There are some but most of the new techs cannot. That is because the tools in the hardware area have been automated to the extent that hardware is yank and replace. Software tools will reach that goal sometime but until then there is work to be had. thanx, bill will work for cash and other incentives [link\|http://home.tampabay.rr.com/boxley/resume/Resume.html\|skill set] "Money for jobs? No first you get the job, then you get the money" Raimondo
Post #61,114 by tseliot 11/5/02 12:08:08 AM Reply	Do you feel... 1. You keep "working yourself out of a job"? and/or 2. You're going to eventually work yourself out of a career? I think lots of current IT workers see #1 but not #2. I wonder how many will hit #2 soon and be surprised by it; i.e. they don't see ossification in their own skill set. If not because of technology passing me by, I can at least see working myself out of a career out of sheer boredom. ;) Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
Post #61,147 by boxley 11/5/02 10:05:31 AM Reply	2 of course except for the boffins that design the new stuff and 3rd line Cust Supp all of the rest will be drones managers and one headsup consultant on call I will be that consultant until I get bored. thanx bill will work for cash and other incentives [link\|http://home.tampabay.rr.com/boxley/resume/Resume.html\|skill set] "Money for jobs? No first you get the job, then you get the money" Raimondo
Post #61,083 by drewk 11/4/02 8:02:33 PM Reply	Don't know how to answer that If you ask the accountants at a real estate business what their industry is, would they say accounting or real estate? Serious question, how do other people answer this one? Because I do web programming at a real estate business. So is "my" subindustry web programming or real estate? === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #61,113 by tseliot 11/5/02 12:03:50 AM Reply	I was interested in the web part. Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
Post #61,138 by drewk 11/5/02 9:10:34 AM Reply	Well ... I'm reminded of a favorite quote from a couple of years ago: "E-business" won't be mainstream until you can drop the "e" and just call it "business". Right now I'm a web programmer. Defined as I program applications for delivery through a web browser, served by a web server. The logic and structure of it is essentially stateless client-server. There is no inherrent "webness" to what I do. So I prefer my official title: programmer. It's a quirk of this young industry that people (mainly HR and PHBs) think there's a difference between a "programmer" and a "web programmer". If we decided tomorrow to redo our intra/extranet as an installable program that happens to use the internet for communication, I'd still be one of the ones doing it. Now that that's out of the way ... My industry is nowhere near automating people out of work yet. System installation and configuration is nearing full automation. System administration is starting down that road, but is nowhere near as far along as Microsoft would like us to believe. But programming can't be automated until we've solved the problem of natural language recognition. You'd have to be able to state a business problem in plain english and the tool converts that into code. So if we're talking about real-estate, that problem domain may be "solved" within another five years. But general programming will be around for a while. === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #61,160 by dshellman 11/5/02 12:39:23 PM Reply	Re: Well ... Actually, I have to somewhat disagree with this: It's a quirk of this young industry that people (mainly HR and PHBs) think there's a difference between a "programmer" and a "web programmer". If we decided tomorrow to redo our intra/extranet as an installable program that happens to use the internet for communication, I'd still be one of the ones doing it. If we were to assume that that programmer had some formal education in programming (computer science, math, EE, etc.), then you might be closer to the truth. My experience has shown that many programmers (and non-programmers, especially) coming from the client/server world stumble quite a bit with the web. That doesn't mean that web programming is inherently (sp?) than client/server or any other distributed (or non-distributed) model. What it means is that there are plenty of gotchas, and a paradigm of looking at how things work. When I see a client/server programmer (that usually isn't that experienced with programming) start coding for the web, they make all sorts of mistakes (such as over-using session objects, organizing pages incorrectly, organizing forms improperly, etc.). The same would go for doing the reverse. If you took a web programmer and threw him/her at a CORBA project, many mistakes will be made. And that's assuming some training. Given enough training, and that may not be a problem...but, then, if you've got special training, you're more than a general purpose programmer (or a web-specific or RPC-specific programmer). With better and better tools, though, those mistakes lessen (and possibly go away). That type of development becomes commoditized (meaning that new college graduates can do it for a lot less money). Web development is certainly headed that way. Of course, there will always be the "more difficult" types of things to do, which will require a more experienced individual, but as the maturation of the "subindustry" grows, the need for those types of individuals lessens. I can read the writing on the wall for what I do...and, hence, I'm working to move beyond it. I've already become too expensive as a simple programmer. For most things, somewhat that's a lot cheaper can do it just as well (or, at least, good enough and fast enough). I'm not going to compete on speed (there's no way to really use that in an interview, and I don't want to work that way), and if my specialized knowledge isn't needed, I'm not (and I don't believe in hording it, so it's easier to work myself out of a job). Dan
Post #61,162 by drewk 11/5/02 12:53:02 PM Reply	I think we've leapfrogged the technology If we were to assume that that programmer had some formal education in programming (computer science, math, EE, etc.), then you might be closer to the truth ... With better and better tools, though, those mistakes lessen (and possibly go away). That type of development becomes commoditized (meaning that new college graduates can do it for a lot less money). I agree with the problem, but think the cause is that our expectations have outpaced the technology. Because of the immaturity of the tools, a good programmer still must have some theoretical background beyond their specific toolset. Eventually the tools will be mature enough to allow specialization, by automating the "generic programming" aspect. But until the tools reach that point, a good programmer will still probably have to know more about programming than about a specific problem domain. === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #61,168 by dshellman 11/5/02 1:11:33 PM Reply	Agreed
Post #61,243 by ben_tilly 11/5/02 6:49:25 PM Reply	And this differs from any other pair of technologies..how? Take any technology. I maintain that programmers who are only familiar with that will make characteristic mistakes when asked to perform with any other technology. How many, how big, and what they are depends on the pair of technologies. That there will be some is inevitable. Cheers, Ben "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #61,329 by dshellman 11/6/02 9:40:09 AM Reply	Riding the waves I completely agree. My point wasn't to make web development and other distributed development models special (I was merely following the example given). What that means, though, is that for a particular type of technology (whether that's web development, client/server, enterprise integration, etc.) it takes time for the tools to reach a point where inexperienced to non-programmers are able to produce applications quickly and with somewhat acceptable quality (obviously, this is somewhat debatable, hence the acceptable quality). Until tools reach that parity, experienced developers with the technology will be in high demand (assuming the technology is in high demand). From a developer's perspective (a highly skilled one, that is), sticking with a particular technology until it's been "tooled" out isn't necessarily a good idea. Of course, there are some examples for and against this: COBOL, which everyone claimed was dead, is still fairly big (even after the spike in 1998-9); though C (not C++) development has tapered off over the years (being replaced mostly by C++/C#/Java), though still has a fairly large niche (Linux, Unix, drivers, etc.); VB and Delphi relegated PowerBuilder (and to some extent Visual C++) to niche-sized markets; and, of course, even Office, with VBA, macros, Access, etc., has made programmers out of power users. None of this is new, of course. I guess my point is that, for the past 20 years or so, there have been waves of technologies which have required experienced developers, admins, etc. to scratch a business itch. Those that have ridden those waves have done well (financially), but when they've ridden them too long or too much, it makes it harder to jump onto the next wave (and demand for them has gone down). Dan
Post #61,124 by CRConrad 11/5/02 3:02:31 AM Reply	That would seem to indicate that... We spend 99% of our time on the applications and the rest on improving the tools we use for application development. Until someone (with control of the purse strings) sees the value of having people actually work on the tools, this isn't about to change. ...that, regardless of where you're at on Bob's line of ever-increasing automation, your movement along that line, towards the point where you've automated yourself out of a job or career, is rather slow. 'Coz the rate of movement oughta be more or less directly proportional to the proportion of time you spend working on the tools, I mean. Note that this is of course disregarding the possibility that you use tools other people make, which they spend pretty much all their time on: For the purposes of a wider discussion, the percentage should be industry-wide, not company-specific. (Which brings us neatly back to your question about how to define "industry"! :-) Christian R. Conrad Microsoft is a true reflection of Bill Gates' personality - the sleaziest, most unethical, ugliest little rat's ass the world has seen unto this time. -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=42971\|Andrew Grygus]
Post #61,136 by drewk 11/5/02 8:50:25 AM Reply	What I mean We use PHP. I have no problem admitting that the development environment for ASP is much richer than that for PHP. All of our database interaction, for instance, has to be done manually. We've created classes to abstract the nitty-gritty, but we still have to interact with it at a fairly low level. Granted, one of the problems with ASP is that it encourages people to not bother understanding what they're doing. But the promise that you shouldn't need to know that is the goal. So for now instead of having to type five lines of code every time we want to query a database, we only have to type three. Sure, there's better error handling and reporting, and we've got some convenience and debugging features built in. But we all know the DB abstraction class could be improved. But until we have time to re-write every single page that touches the existing class, it's a non-starter. We've discussed versioning, but the code is bloated enough without introducing our own layer of class-version hell. === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #61,563 by tablizer 11/7/02 3:16:40 AM 11/7/02 3:21:05 AM Reply	PHP database code? All of our database interaction, for instance, has to be done manually. \r\n \r\nI am not sure what you mean by "manually".\r\n \r\n \r\n So for now instead of having to type five lines of code every time we want to query a database, we only have to type three. \r\n \r\n \r\nIf you use mostly one (standard) connection throughout the app, then most query calls can be reduced to something like:\r\n \r\n \r\nrow = myQueryWrapper("select * from foo")\r\nwhile getNext(row) { // for each row in result set\r\n print("Amount is " & row['amt'])\r\n ....\r\n}\r\n \r\nBoth ASP and PHP can do something like this (although ASP requires a MoveNext IIRC). I am not sure where the bottleneck is in your simplification attempt.\r\n \r\nI take that back. I think you need two different handles minimum for PHP (assuming MySQL API). I'll have to experiment to verify that.\r\n ________________\r\noop.ismad.com Edited by tablizer Nov. 7, 2002, 03:21:05 AM EST Expand All History
Post #61,586 by drewk 11/7/02 9:43:12 AM Reply	What I mean by "manually" We have to specify which DB server, which database and which table for every query. For pages that deal exclusively with one database we can set up the single connection and re-use it. I know you don't like OO,, but that's how we write our PHP. Since we're using OO programming to interface with an RDBMS, there is an "impedance mismatch". If we had an object/relational database, we could define the objects in the DB and query things much more naturally. So instead of $db = new objDB( "db_server_1" );\n$sql = "SELECT \n tbl_user.*,\n tbl_office.addr1 AS office_addr1,\n tbl_office.addr2 AS office_addr2,\n tbl_office.city AS office_city,\n tbl_office.state AS office_state,\n tbl_office.zip AS office_zip,\n tbl_office.phone AS office_phone,\n tbl_office.fax AS office_fax\nFROM\n db_user.tbl_user,\n db_office.tbl_office\nWHERE\n tbl_user.office_id = tbl_office.id\n AND tbl_user.id = '$user_id'";\n$db->query( $sql ) we could use $db = new objDB();\n$db->query( "GET user '$id'") That's what I mean by "manually". === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #61,661 by tablizer 11/7/02 1:15:33 PM Reply	inter-paradigm translation costs Since we're using OO programming to interface with an RDBMS, there is an "impedance mismatch". If we had an object/relational database, we could define the objects in the DB and query things much more naturally. Since you don't have an ORDB nor an OODB, perhaps it would make sense to stop trying. IOW, give up on OO so that you are not constantly battling paradigm translation/adaption issues. I suppose your response is that OO is so useful that the translation costs are still worth it. Is OO really that much more useful in your mind that you are willing to spend such translation/adapting costs to have OO? I won't fuss if you say, "yes", I just want to confirm if this is your reasoning for pursuing it despite an admitted translation tax. ________________ oop.ismad.com
Post #61,664 by drewk 11/7/02 1:23:38 PM Reply	Yes === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #61,181 by wharris2 11/5/02 1:58:48 PM Reply	Another take Encroachment of non-programmers into programmer-space has been happening, on a faster and faster basis, for twenty-five or thirty years. Probably starting with the earliest spreadsheets, and progressing through Visual-This-n-That kinds of tools. Some tools are there today. Front Page may emit klunky HTML and miserable pages, but it'll allow even a novice to lay out a Web page. Joe Sixpack may not be able to create an optimal database in Access or Paradox or whatever, but he can create something usable for him. But for the forseeable future, there's going to be a need to have to be someone like a programmer (or, if you want to be fancy, systems analyst) who really knows how things work and how to translate a user's wishes/the government's regulations/or whatever into a form the computer can understand. Better and better tools may lower the bar, but they aren't going to eliminate it. Joe Sixpack will be able to create a database, but unless he acquires more DBA or programming savvy he won't know why some choices are better than others.
Post #61,242 by tjsinclair 11/5/02 6:47:41 PM Reply	That's a growing problem at technical schools Well, at least at mine. Our students want to take the easy way out and use a code-generating tool instead of understanding the code itself. I don't have any problem with them using the tool, but if they don't know the material then we're not doing our jobs. For example, I'm teaching an introductory HTML class this term. I had a discussion with my students explaining why we were learning to code by hand when there were so many tools that would automatically generate HTML. It boiled down to two reasons: - Most tools generate crappy, non-standard code and you need to know how to fix it. (If the tool will let you.) - Most Web pages use dynamically generated content so a good working knowledge of HTML will help you script a dynamic Web page. (Or troubleshoot it.) I've already made clear my position that we do students no favors by teaching them VB. VB and Perl are now both 'campus-optional'. (Guess which one we teach on my campus?) Anyway, I agree that there will always be a need for people who understand the technology, just not so many of them. Tom Sinclair "Everybody is someone else's weirdo." - E. Dijkstra
Post #61,253 by a6l6e6x 11/5/02 7:54:05 PM Reply	Reminds me of first computer related course that I took... (over 40 years ago). So that we would appreciate what an assembler did for us, in the first lab assignment, we had to write the machine code w/o instruction mnemonics but as constants. Imagine, if you will, line after line of octal constants. For one thing, it made you realize the mnemonics were somewhat arbitrary. Alex "I have a truly marvelous demonstration of this proposition which this margin is too narrow to contain. -- Pierre de Fermat (1601-1665)
Post #61,255 by jake123 11/5/02 8:04:55 PM Reply	Real Story I'm working with a young woman (no titters please;) who just finished a college course in web programming. I should point out that what you US folks call a college, we call a university; this is a technical course that covers a topic in one year at a private school. I've quizzed her a bit about what they taught her. So far, she doesn't grok: OO vs. Functional programming paradigms: what are they? STDIN, STDOUT, and STDERR: what are they and why they matter to web programming? Exactly what CGI is (she couldn't even get the acronym right, let alone describe how it works!). On the subject of OO programming: What's a method? What's inheritance? What's polymorphism? What's a class? On the subject of Functional programming: What's a function? Why do you want to reuse code by putting them into functions? What are function calls... and where are likely places where one might find functions you can use? So far, she's been batting 0 as in zero as in nada as in SFA. What they did teach her was how to use Visual Interdev to create ASP pages, a smattering of VBScript, and HTML and CSS... though I'm not entirely sure she has a complete grasp on how those last two fit together. As the final kicker, she does her source editing in Microsoft Word... she had to do her coursework in Word, and has just gotten used to how you do that. Furthermore, the other web people at this company all use Word to do their editing (and I'm not talking about "Save as HTML" I'm talking about cranking out tags in Word and saving it as a text file... «shudder») Now don't get me wrong... she's a nice woman, bright, and we've actually had some good conversations about how programming works... and she's picked it up pretty quickly. However, with this kind of training going on (and it appears to be depressingly common) I don't think anybody here has to fear for their job quite yet... --\r\n-------------------------------------------------------------------\r\n* Jack Troughton jake at consultron.ca \r\n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \r\n Laval Qu\ufffdbec Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\r\n-------------------------------------------------------------------
Post #61,311 by drewk 11/6/02 8:17:24 AM Reply	Don't I wish However, with this kind of training going on (and it appears to be depressingly common) I don't think anybody here has to fear for their job quite yet... You seem to assume the people doing hiring/firing would know to ask those questions. === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #61,355 by jake123 11/6/02 10:44:53 AM Reply	Re: Don't I wish While it's true that a particular instance might result in employment change... in the medium term the people that actually know the concepts will be more secure. Kinda like how an MCSE holds no water anymore; too many employers have seen the newly minted MCSE come in and fuck everything up bigtime. At this point, MCSE is not perceived as a net benefit... that's why MSFT tried to clean up the program a year or two ago. --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Laval Qu\ufffdbec Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n-------------------------------------------------------------------
Post #61,580 by Simon_Jester 11/7/02 9:03:38 AM Reply	Web Programming and OO? College was a few years ago, but when I hear of functional programming languages, I think of LISP rather than C/Pascal/etc. (The books we had then had them as imperative language, iirc). But I am curious. (I've avoided almost all web programming. :-) But is there that much OO in JavaScript and others? (Perl seems to have tacked on 00, but...) (I don't think there's any OO in HTML, but I could be completely wrong). I'm trying to think of why she should be aware of OO techniques if she's doing web pages.
Post #61,583 by drewk 11/7/02 9:27:37 AM Reply	Couple of answers First, HTML is a markup language, not a programming language, so it isn't meaningful to ask if it is OO. Second, the reason somone "doing" web pages should know about programming is that any large site eventually involves programming. The content has to be dropped into a framework, and someone has to know how to build that framework. Then add search functionality, feedback, shopping carts ... unless you want to be strictly a graphic designer, you're going to have to know this stuff. === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #61,584 by admin 11/7/02 9:34:03 AM Reply	Javascript is like Python wrt OO It can be as OO as you want it to be for the most part. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #61,676 by tablizer 11/7/02 2:03:35 PM 11/7/02 2:12:28 PM Reply	re: Javascript is like Python wrt OO IIRC, JavaScript (JS) and Python handle inheritance very differently. Python objects can have an explicit "search path" to hunt parent class/objects. But in JS you "clone" the parent to inherit from it, and then override what you want overridden in the copy (child). There is no explicit parent search path list in JS I don't think. It is purely inheritance-by-cloning. (Whether that is good or bad I won't say.) Correction: It seems later versions of JS added a "prototype" property, which is essentially a search path, a pointer to the "parent" object/class. In dynamic OO languages, objects are often simply dictionary arrays where the slots can hold attributes or code (or code pointer), and with a parent-search-path of some sort for upward hunts of any non-matching keys in the current array. ________________ oop.ismad.com Edited by tablizer Nov. 7, 2002, 02:12:28 PM EST Expand All History
Post #61,678 by admin 11/7/02 2:07:39 PM Reply	That wasn't my point. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #61,595 by ChrisR 11/7/02 10:07:50 AM Reply	Functional programming languages College was a few years ago, but when I hear of functional programming languages, I think of LISP rather than C/Pascal/etc. (The books we had then had them as imperative language, iirc). The trick to Lisp is that it is flexible enuf to be able to use in any programming language paradigm ever invented. Strictly speaking, Scheme - a derivative of Lisp - is more commonly associated with FP. From a purity perspective, Haskell, Mercury and SML come about the closest (see [link\|http://www.cs.nott.ac.uk/~gmh//faq.html\|Functional Programming FAQ]).
Post #61,648 by jake123 11/7/02 12:33:32 PM Reply	Why OO techniques in web programming Using one of several interfaces available on web servers lets designers write programs to do certain tasks. For example, at my website, I built an indexing program in Object REXX which lets me reindex my program automagically. The resulting index is stuffed into memory (in the .environment object, specifically) where it can be accessed by other CGIs I've written. For an example, go to [link\|http://consultron.ca/english\|http://consultron.ca/english] and look at the nav menu on the left. Also, look at the sitemap page... that's generated by a program too. The nice thing about this is that I can add content to my site, and so long as I follow a few conventions in my pages (look at the meta tags to see what they are) I can just run a little program to add it to the site's index. After that, the menu program and the sitemap program just add them to the navigation controls. It makes dealing with adding content or changing content a lot easier than it would otherwise be. This all happens server side... when one uses the CGI interface, all one has to do is to make sure that the generated html comes out of stdout. The program can be written in any language that the host supports. Considering what a DOM is, using OO techniques can make that sort of thing a lot easier, a lot cleaner, and a lot more extensible with less effort than it would be if one was taking a procedural or functional approach. In fact, a large part of what I did was to apply the concept of a DOM to the server and site as a whole. --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Laval Qu\ufffdbec Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n-------------------------------------------------------------------
Post #61,671 by tablizer 11/7/02 1:38:12 PM Reply	why does that need OO? For an example, go to [link\|http://consultron.ca/english\|http://consultron.ca/english] and look at the nav menu on the left. Also, look at the sitemap page... that's generated by a program too. The nice thing about this is that I can add content to my site, and so long as I follow a few conventions in my pages I don't see why this needs OO. I have done similar things before using table-oriented approaches. A rough example table layout can be seen at [link\|http://geocities.com/tablizer/cntrl1.htm#website\|http://geocities.com...ntrl1.htm#website] ________________ oop.ismad.com
Post #61,675 by jake123 11/7/02 1:59:09 PM Reply	It doesn't. It just makes it a lot easier. Have you ever actually tried to learn how OO programming works? --\r\n-------------------------------------------------------------------\r\n* Jack Troughton jake at consultron.ca \r\n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \r\n Laval Qu\ufffdbec Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\r\n-------------------------------------------------------------------
Post #61,680 by tablizer 11/7/02 2:22:32 PM Reply	Of course I don't believe you It doesn't. [OO] just makes it a lot easier. Of course, I don't believe you. "A lot" implies a demonstration is a sinch. It is the subtle differences that are hard to demonstrate. Have you ever actually tried to learn how OO programming works? Have you actually tried to learn how tables work? Have you actually tried to learn how to articulate benefits without personal insults? Have you stopped beating your wife? (He started it. I made no references to people being weak/bad, only technologies. He turned it into an issue of personal faults/lackings. I have to point these kind of things things out because I am often falsely accused of stirring trouble. Thus I have to be anal about who starts what. Insulting technologies is fair game. Insulting people is not. True, I admit I slip sometimes, but this is NOT one of them.) ________________ oop.ismad.com
Post #61,681 by jake123 11/7/02 2:25:22 PM Reply	Whatever you say, sunshine. --\r\n-------------------------------------------------------------------\r\n* Jack Troughton jake at consultron.ca \r\n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \r\n Laval Qu\ufffdbec Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\r\n-------------------------------------------------------------------
Post #61,683 by tablizer 11/7/02 2:34:40 PM Reply	I was hoping for a technical comparison, not flame-bait ________________ oop.ismad.com
Post #61,691 by jake123 11/7/02 3:35:37 PM Reply	Re: I was hoping for a technical comparison, not flame-bait Who started flaming? I asked you if you had actually tried learning OO... I've seen you demonstrate some serious ignorance on the subject. \r\n\r\n The reason I asked is because I've seen you try to use tables as the solution to every problem... when all you have is a hammer, everything looks like a nail. I don't use OO programming for everything... the scripts that I wrote for the timestamps and uptimes are procedural, because an OO approach is wrong for those problems. OTOH, building an index for a web server (including virtual hosted websites, folders within those websites, and pages within those folders) is a problem that is very easily addressed by creating objects that represent those entities, as well as directories (tables implemented as an object in to ORexx language spec) containing index objects that point to those entities. The result of this is that there are many ways to get to a particular object representing one of those entities depending on what the problem you're trying to solve is. \r\n\r\n For example, here's a simplified representation of the structure of a web server object in my program: \r\n\r\n web server\r\n +websites\r\n +Site1\r\n +index\r\n +indexitem\r\n +page\r\n +page's parent(always a web folder)\r\n +root folder\r\n +folder's properties (URL, Link Title, etc)\r\n +SubPage array\r\n +Page1\r\n +Page2\r\n +SubFolder array\r\n +Folder1\r\n +Folder2\r\n +Site2\r\n + ...\r\n +siteroot\r\n \r\n By doing this, I can greatly simplify the programs that create the navigation menus etc. Here's the one that makes the sitemap for the site: \r\n\r\n /* sitemap.cmd - build sitemap for web site /\r\nsite = .web.server[website][1]\r\n\r\nmenuroot = site[root]\r\n\r\nif menuroot~hasindex('SUBDIR') then call sayfolders menuroot[subdir]\r\n\r\nif menuroot~hasindex('PAGE') then call saypages menuroot[page]\r\n\r\n\r\n \r\n::routine sayfolders\r\nuse arg folderarray, \r\n\r\nsay '<ul>'\r\n\r\ndo i = 1 to folderarray~items\r\n say '<li>'\r\n say folderarray[i][link]~saylink \|\| ' - ' \|\| folderarray[i][meta]['Description']\r\n say '</li>'\r\n if folderarray[i]~hasindex('SUBDIR') then call sayfolders folderarray[i][subdir]\r\n if folderarray[i]~hasindex('PAGE') then call saypages folderarray[i][page]\r\nend\r\n\r\nsay '</ul>'\r\n\r\n::routine saypages\r\nuse arg pagearray, curpage\r\n\r\nsay '<dl>'\r\n\r\ndo i = 1 to pagearray~items\r\n say '<dt>'\r\n say pagearray[i][link]~saylink \|\| ' - ' \|\| pagearray[i][meta]['Description']\r\n say '</dt>'\r\nend\r\n\r\nsay '</dl>'\r\n \r\n Very nice, very neat, and it's very clear what's going on. Trying to do the same thing with a procedural type of program would be a lot more work. The key is in the classes I created, and the methods I created for them. The other key is that when I stuff the "current" object into the loop object, I can refer to it very easily, even though the actual name of the object itself can be very very large for a deeply nested webpage. It makes for much clearer code, and also makes for very easy maintainability. --\r\n-------------------------------------------------------------------\r\n Jack Troughton jake at consultron.ca \r\n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \r\n Laval Qu\ufffdbec Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\r\n-------------------------------------------------------------------
Post #61,693 by admin 11/7/02 3:43:08 PM Reply	Start a new thread if you two get into it :-) Check the "As New Topic" box under the save button. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #61,699 by tablizer 11/7/02 4:21:03 PM Reply	Should we put it in the Flame Quarentine section? ________________ oop.ismad.com
Post #61,698 by tablizer 11/7/02 4:19:36 PM 11/7/02 9:12:04 PM Reply	just recursion there Who started flaming? I asked you if you had actually tried learning OO It sounded suspiciously similar to some personal insults from others. If you meant it seriously, then perhaps there are more diplomatic alternatives to asking the same thing. For example, "What is your level of knowledge of OO?" I've seen you demonstrate some serious ignorance on the subject. I have been tripped on language-specific trivia and vocab in the past, but never anything fundimental to understanding OO itself. (Well OK, Visitor still tosses me, I admit.) May I ask what this alleged big faulup was? Perhaps you are too eager to believe the FUD from those who hold big grudges against me left over from heated arguments. The reason I asked is because I've seen you try to use tables as the solution to every problem... when all you have is a hammer, everything looks like a nail. I could say the same about you guys and objects/classes. Objects/classes appear to me nothing more than a crippled collection: a vertical dictionary (hash) array with a search path to optional parent(s) if key is not found in current dict. (The dict keys are the attribute or method name and the value is an attribute value or an algorithm {method} pointer or code.) That is what OO boils down to in my mind. Dictionaries are fine for simple short-term interfaces, but I would not want to build and manage large-scale structures with them alone. IOW, they are too crippled to serve as a primary building block of everything. Dictionaries have some arbitrary limits on them: Only one "match" max, two columns, and one index. This 1,2,1 is an arbitrary set of (low) numbers. They are not universal constants or anything. IOW, tables make a more open-ended hammer. I am not limited by 1,2,1. I can have a 12,243,17 if I want. The result of this is that there are many ways to get to a particular object representing one of those entities depending on what the problem you're trying to solve is. That is what relational queries are like. You give a little relational equation that merges, filters, sorts, etc. the data into just about any organization you can imagine. Isn't it agreed that relational DB's are better at ad-hoc queries than DB-free OO techniques? Not that ad-hoc queries are the end-all-be-all, but that compact flexibility spills over into the rest of the p/r design also. I don't want to manage indexes in programming code (as arrays or linked lists, etc.), I want to farm that off to the DB engine. Arrays and linked lists feel too "low level" to me. Plus, it is hard to traverse them without going through the parent's interface first. Some queries don't need the parent. Trying to do the same thing with a procedural type of program would be a lot more work. I don't think so. You have nothing but simple recursion here. Besides, some RDBMS, like Oracle, have built-in tree operations so that you don't have to do recursion in your code. (One drawback in the Oracle approach could be different entities at different levels, though. I would have to look at some more specifics of your requirments.) My designs tend to be less "nesty", so I don't use/need tree-centric operations/algorithms that much (if given a choice). Trees don't scale, IMO. For example, product categories tend to grow non-tree over time because products end up in orthogonal or semi-orthogonal (multiple) categories. BTW, what is a subpage or subfolder in your setup? ________________ oop.ismad.com Edited by tablizer Nov. 7, 2002, 09:12:04 PM EST Expand All History
Post #61,877 by jake123 11/8/02 12:13:49 PM Reply	Recursion not the point; it's object references (new thread) Created as new thread #61876 titled [link\|/forums/render/content/show?contentid=61876\|Recursion not the point; it's object references] --\r\n-------------------------------------------------------------------\r\n* Jack Troughton jake at consultron.ca \r\n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \r\n Laval Qu\ufffdbec Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\r\n-------------------------------------------------------------------
Post #61,156 by Arkadiy 11/5/02 11:31:07 AM Reply	Low-level programming is here to stay. Somebody has to create those elements that end users will snap together. In addition, most people have hard time thinking in terms of nested data and control structures. End users work best when you can show them a picture or a linear narrative. Start using loops, nested ifs, 5 levels of tables - you get blank stares. And those things are needed to accomplish many tasks that computers are used for. In general, we will need fewer and fewer programmers, but those we need will have to be better and better. At some point it will place me out of the game, obviously. Hopefully, by then I'll be ready to retire :) . -- We have only 2 things to worry about: That things will never get back to normal, and that they already have.
Post #61,252 by static 11/5/02 7:52:29 PM Reply	I don't quite agree. I'm one of those low-level programmers, but even after coming up two or three levels of abstraction, some things are still too complex for many of our end-users. We will probably end up training two or three people at each client installation how to customize and build their reports with our interface. The ideal people for this role are those who can program their VCR but wouldn't grok our database structure. Wade. "Ah. One of the difficult questions."
Post #61,328 by Arkadiy 11/6/02 9:36:18 AM Reply	I was trying to say the same thing. -- We have only 2 things to worry about: That things will never get back to normal, and that they already have.
Post #61,473 by tuberculosis 11/6/02 6:04:20 PM 8/21/07 5:40:15 AM Reply	I don't personally believe in end user programming. Because I've seen the really crummy stuff novices create with 4GL tools. Its generally unusable stuff. What I am annoyed about is management classifying software development at about the same level of difficulty as typing. We are viewed as unskilled labor exportable overseas to cheaper parts of the world. Line workers. This bothers me a lot. I also think that programming as it is defined today is broken. The current crop of popular languages are lame platypi lacking synergy and focus. The world wide web and most of its hosted apps are an assemblage of chewing gum and toilet paper. The gum and paper are of elaborate design with special properties devised by roving throngs of cocktail party politicians jockeying for favorable position in a competitive landscape - standards are always designed to screw someone. I don't think programming is automatable, but I do think infrastructure could be put into place to elevate the conceptual level at which we operate if the big 800 lb gorillas would quit trying to crush each other. There is a group working towards a virtual machine that is truly general purpose - whether they can succeed and gain adoption remains to be seen. I am out of the country for the duration of the Bush administration. Please leave a message and I'll get back to you when democracy returns. Edited by tuberculosis Aug. 21, 2007, 05:40:15 AM EDT Expand All History
Post #61,556 by tablizer 11/7/02 2:26:20 AM Reply	human factors bust automation goals Because I've seen the really crummy stuff novices create with 4GL tools. Its generally unusable stuff. What I am annoyed about is management classifying software development at about the same level of difficulty as typing. We are viewed as unskilled labor exportable overseas to cheaper parts of the world. Line workers. Agreed. It is relatively easy to get something running from scratch using Access or what-not. However, amatures have almost ZILCH understanding/skills of long-term maintainability. However, kudos for maintainability skill are generally rare in comming. That is the big contradiction of the industry IMO. Bosses don't know what is good for them, jugding things on superficial sh8t instead. Yes, newbies and end users can create applications with drag-n-drool tools, but eventually they will make a mess. It is like gunk build-up in arteries or bad oil in your car. It may not kill the machine today, but it will in the end. A lot of programming expenditure today is cleaning up, navigating, or patching messes made by idiots. I would go as far to say that messes made by idiots is the most expensive part of custom software. So as long as there are idiots, there will be jobs for people to deal with or clean up the messes. However, such work is usually not very pleasent IMO. It is similar in feeling to spending time to untangle your toddler's yoyo. Another factor keeping the profession alive is "ego-based tinkering". Managers love to customize stuff. It makes them feel important. Generic tools could be made to handle roughly say 90% of what they want, but its the last 10% that turns them to more skilled people. Finally, many business rules are too complex and capricous to automate with drag-n-drool end-user tools. I liken it to building an AI system that tries to model the current head honcho's head. I think GUI's and add/change/delete forms could be greatly simplified, especially for web apps, but the nitty business rules behind a lot of that are not generic enough to package and share. IOW, many biz rules are not rational enough to apply rational abstraction to. Thus, there are 3 factors that keep the profession alive: 1. Newbies/amatures tend to make messes that accumulate over time. 2. Fine-tuned customization makes managers feel important. 3. Biz rules are too tied to whims and flakiness of big-wig personalities rather than reflecting factorable true-isms about the universe. What I see as a bigger threat to programming is cheap foreign labor (both abroad and visas). Even if it does not directly replace your job, it will toss a lot of developers into the job pool, bumping other citizens your way and diluting citizen earning power and market demand. ________________ oop.ismad.com
Post #61,692 by wharris2 11/7/02 3:39:10 PM Reply	Re: human factors bust automation goals However, amatures have almost ZILCH understanding/skills of long-term maintainability. However, kudos for maintainability skill are generally rare in comming. That is the big contradiction of the industry IMO. Bosses don't know what is good for them, jugding things on superficial sh8t instead. Actually, notice of this type of things usually comes from your peers rather than the PHB's. There's nothing quite like being told by someone (assigned to make a change to a program you originally wrote) that it was easy to make the modification to it. (The one I'm thinking of, about the third or fourth program I wrote after I joined the programming work force, is IMO a pile of gently steaming crud, but it was nice to hear that someone thought it was halfway decent code even if I disagree with them on that. :-)
Post #61,709 by tablizer 11/7/02 5:03:21 PM Reply	re: Peer Kudos Actually, notice of this type of things usually comes from your peers rather than the PHB's. There's nothing quite like being told by [another developer] that it was easy to make the modification to it. True, but that often does not translate into more pay. I am not saying that personal satisfaction is not a good reward in itself, but on a large scale there is not a lot of financial incentive for programmers in general to write maintainable code in most shops I see. (Hmmm. I don't remember that many "however's" in my text. It was fine when I proofread it. Aliens changed it! My foil hat is not working.) ________________ oop.ismad.com

Welcome to IWETHEY!