Yep

Post #47,982 by tuberculosis 8/3/02 6:23:31 PM Reply	Yep I'm in the same boat. Lets start with the fact that the dominant programming language in the industry has a bunch of stupid limitations because the designer (James Gosling - either idiot or asshole, I cant quite decide) wanted to make it hard for yo-yos to hang themselves. Isn't that just lovely? Since you're afraid to fly I have to turn in my wings? Fuck you and your crack induced toy language you lightweight. When I first read about the dilbert principle I thought it was a joke. Only in my last company it came forth in vivid color. An idiot contractor who couldn't code his way out of a paper bag was given the role of project tracker, which grew into project manager during a senior management coup. I took to calling him clippy as I viewed him as nothing but an avatar for MS Project. Not only that, clippy stayed in my face and claimed I was being uncooperative when he couldn't understand my answers to his questions and I refused to rewrite them in crayon with smaller words. The company before that I got hired in as chief architect, busted my ass to build prototype to raise many millions of dollars, only to be replaced by clueless consultant because I'm grumpy when I work 90 hours a week. Clueless immediately eliminated my position and wasted all the money rewriting my previous years work with a team of 12 and it didn't work as well. Company ran out of money before they could break into new territory. Problem is management can't tell shit from shineola. So why not just give em shit. Thats what I'm doing. I think the most impressive people are working on Squeak, but they are idiot savants with no commercial motivation and no sense of essential features to build a business platform. There's cool research going on there but its pretty much all masturbation. Meanwhile we keep getting more and more C++ clones and the complexity mongers keep building out the XML beast. No real power in the tools and elegance hasn't been seen for a long time. Its a living though. 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.
Post #47,983 by gdaustin 8/3/02 7:43:05 PM Reply	So, you hate Java, eh? What do you suggest? Assembler? Java is a good language for some things. We use Java it for server stuff, the thread/socket classes make it very fast to develop scalable server-based programs. RAD is a major priority where I work. The JDBC libraries rock in getting access to a large variety of databases. In big Sun and HP systems (probably in AIX, too), this stuff really rocks because it is very quick to develop with few mistakes. We've had memory leaks even in Java, but they're more difficult to create. I have problems with the GUI in Java, not because it's not a good GUI, but because the owner of our company has non-programmers developing the GUI components of the program (the forms, buttons, lists, etc. ) and you have to be a programmer to understand the layout manager in Java. So, because we can't afford to hire real programmers to do GUI development, we use hourly help-desk employees to develop screens. (I'm not happy about it, but that's the way IT is.) Our shop is IBM PC Assember (small model, from the Reagan Administration), but we still have 2 employees who manage to keep those systems running. We are trying desparately to replace the systems before the 2 Assembler employees decide they can't stand it anymore. One is already interviewing. Next language is Delphi. Originally, I wasn't a Pascal fan at all. But, I will admit that GUI development is very easy and quick, and we have a lot of really cool tool libraries (Raize, Woll2Woll, jedi) that REALLY make it easy. I wrote Pascal 15 years ago, and it was nothing this week to pick up the language and start coding in it, to help our 3 Delphi programmers with some serious system problems. And I really need to dig into the OO parts of Delphi, since I programmed Pascal in pre-OO days. Our code is crap, though, the (now ex) programmers who coded the system I'm supporting didn't even know how to use function arguments and return codes. Everything is a friggin PROCEDURE! and all the call arguments and return codes are in GLOBALS! Who writes crap like this???? Understand Todd, I'm not a language purist. If you can show me how I can be very productive and build fast and scalable server code in SmallTalk, Eiffel, or C++, I'll do it. But Java works for me, for now. The price is right, too. I'm not a C/C++ fan, not because it's a bad language, but because most developers aren't trained/smart/disciplined enough to write good code in those languages. I find most programs (even in Unix) have memory leaks, memory corruption, and most shops don't enforce good coding practices, so the quality of the code produced is very poor. Most shops have no clue what tools like Bounds Checker and Purify do. Code reviews at most places I worked were a joke. But, I'm a man on a mission with my company. I want to get our Assembler converted to Java, get the Delphi cleaned up, train a decent DBA, and then I'm ready to move to a bigger company ( because the owner does not anyone in control but himself ). Glen Austin
Post #47,995 by Another Scott 8/3/02 11:21:56 PM Reply	IIRC, Todd likes ObjectiveC.
Post #47,998 by mmoffitt 8/3/02 11:54:28 PM Reply	Re: Who writes crap like this? Engineers. Not s/w engineers, but EE's and Mech E's and folks like that who have discovered PC's and VB, or who have chosen Intellution/Wonderware/Rockwell for their HMI needs. I've never seen an app written by an engineer that didn't make excessive use of "globals". I hate cleaning this shit up, but, as you say, it's a living and there is a TON of this kind of shit to clean up. bcnu, Mikem
Post #48,013 by deSitter 8/4/02 2:18:24 AM Reply	Re: Who writes crap like this? Often it is better to use globals when doing numerical calculations in a practical sense. In older days one had FORTRAN with its static store running on machines with restricted memory. A program might have to be chopped into a lot of pieces and you needed a certain way to have the same data available. FORTRAN is a very brute force language and engineers are out to solve specific problems. I know what you mean, but it's not really fair. -drl
Post #48,138 by boxley 8/5/02 10:57:15 AM Reply	Globals, write once run everywhere, whats wrong with that? Trouble with programmers is that they define on the fly with no sensual objective of what huge bucket of crap they are not documenting. Engineers write small modular pieces and generally understand what machine code is and which way the solder drips. Pogrommers are rapid typists writing the great american novel and are surprised when the 2 record database they tested on doesnt behave the way the 200 kajillion records in the production environment. All present company excepted of course and a couple of my buds. thanx, bill ."Once, in the wilds of Afghanistan, I had to subsist on food and water for several weeks." W.C. Fields
Post #48,271 by static 8/5/02 9:26:55 PM Reply	There globals and there are Globals. That is, there globals that stick around for the life of the application and then there are "global" variables within a module with a short lifespan. CGI and web script programming is like that: it's easy to use "global" variables in PHP, but they die when the page is finished. So they only have a short lifespan, unlike global variables in more traditional languages (like C). PHP's equivalent is called session variables, but you have to make a special call to convert a global variable into a session variable. This encourages some discipline. Despite it's other flaws, Visual BASIC was like this. Truly global variables required additional declarations, as did mere module-wide variables. Unfortunately, there was a compile-time option to disable this requirement. Myself, I dislike long-lived, volitale global variables. If I find myself about to use them, I tend to stop and try to fix whatever's broken to require them. Not always possible, note, but I try. Wade. "Ah. One of the difficult questions."
Post #48,016 by tuberculosis 8/4/02 4:24:13 AM Reply	Java Java is a neanderthal dressed in a Brooks Brothers suit. Smalltalk 80 was and is a more advanced language. Primitive types are unnecessary and a huge source of bugs. The "Object" wrappers for primitive types are worthless. Example code: Integer i = new Integer(5); Short s = new Short((short) 5); try { if(i.equals(s)) System.out.println("Java's not so bad"); } catch(Exception ex) { System.out.println("Java sucks - here's 1 reason why: " + ex); } yeah, I'm supposed to take this seriously? I can go on and on - I wrote a few screeds on [link\|http://ventedspleen.weblogger.com\|http://ventedspleen.weblogger.com] before I stopped having time to vent every day. Its just amazing to me that after 50 years of CS research we end up with a trainwreck like Java that disallows real dynamic OO programming. 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.
Post #48,029 by deSitter 8/4/02 10:48:16 AM Reply	Wow It's amazing how ugly it looks on paper. Wow, I am reading a blog and it's actually interesting... -drl
Post #48,032 by deSitter 8/4/02 11:01:43 AM Reply	Crazy Idea In the idea of a paperless office, the fundamental object will be a document, and it might as well exhibit as (virtual) PDF as exhibit as a window. When you wanted to call up a document this PDF would become real, either as print or (possibly interactive) display. This seems oddly SmallTalky but with a modification of the idea of document. I have to come up with an inventory management system for lots a parts from several manufacturers. I wanted to use SmallTalk for this because I sense that the difficult problem will be defining how the inventory flows (what you call business rules). But I don't want the users to see any of the guts and I want to get away from "everything in a web browser". So I guess I want to detach from windows an have explicit, formatted documents displayed. -drl
Post #48,017 by tuberculosis 8/4/02 4:38:26 AM Reply	Ob JDBC If your application programmers ever see JDBC then you might as well whip out the C. JDBC is a useful enabling layer but it doesn't do anything ODBC didn't do and it still directly exposes the structure of the database by exposing SQL. Dumb idea. Using TopLink or something like that is what ought to be the standard. FWIW, the NextStep system, built using ObjectiveC (a decent comprompise between Smalltalk and C) of 1995, was lightyears ahead of where Java is now. For a little taste of what we've lost (the OR Mapper known as EOF has since been grabbed by the WebObjects team and ported to Java for marketing reasons), get a Mac with OSX and learn to write a Cocoa app on it. Freakin amazing it is. Interface Builder is what the Java Bean people were dreaming about and still haven't delivered. The industry is in a state of deevolution. 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.
Post #48,033 by gdaustin 8/4/02 11:08:07 AM Reply	Not exposing the "structure" of the database I'm not buying this argument, Todd, because I've programmed in about 4 flavors of SQL ( Sybase, MS, Oracle, DB2 )for about 6-7 years now. Yes, you can objectivize the structure of the database away using object oriented techniques, but this is a very bad thing, performance-wise. When you're writing software to do mass purges (purging a million rows in 2-3 days) out of a 100 million row database, you can't just "let the object-oriented libraries handle it". There are very specific types of SQL statements you have to write to make it function correctly, or it will perform VERY SLOW, or run the system out of log space. I did that in a previous job. When the structure of the database is abstracted away from the developer, then very bad things happen, like queries that result in table scans on 100 million row tables. This same thing happens when people use things like Rational-Rose, and it happened back in my mainframe days, when people used IEF. The "modeling" tools have no idea what indexes the database has, how many rows certain tables have, etc. and then the "modeling" tool ends up writing code that performs like crap. Bottom line, you HAVE to know the structure/behavior of the database (keys, indexes, rowcounts, access hot spots) to be successful. To the extent that modeling tools remove you from the knowledge of that structure, they are evil. Also, the added layer of object orientation between business logic and data is being preached in n-tier mantras all the time, many times when it is not necessary. I argue against it many times for specific reasons. If the project is entirely internal, with a single interface and a single customer, then it is simply faster to do 2 or 3 tier. OO is useful for interfaces where a non-computer literate customer is attempting to program. A good example is our hourly people at work dropping controls on a screen in Delphi to attempt to build a program. n-tier interfaces need to be defined in complex systems where multiple customers process the same data, and multiple sub-systems are used by multiple customers, and the company needs to reduce costs by sharing the functionality of subsystems, rather than duplicating them (and their costs). Software design needs to be exactly like architecting a building. The interface points, entry/exits for people, water, electicity, gas, and air need to be well defined, carefully placed (where water and electricity are kept apart, for example) in order for a building to be successful. Good software has to be built the same way. In small, homogeneous environments, 2 tier is fine. Glen Austin
Post #48,043 by tuberculosis 8/4/02 1:37:55 PM Reply	Re: Not exposing the "structure" of the database Yes, you can objectivize the structure of the database away using object oriented techniques, but this is a very bad thing, performance-wise. You can't make that statement. Its a huge blanket statement and it can't possibly cover every scenario. For the average crud app, query for a list of objects, do some master-detail navigation, update or insert some data and save, OR Mapping with lazy faulting is the only way to fly. When you're writing software to do mass purges (purging a million rows in 2-3 days) out of a 100 million row database, you can't just "let the object-oriented libraries handle it". Uh huh. How many apps that the average developer is going to write are going to do that? Exactly Zero. That's a db maintenance function to be performed by an administrator and yes you write SQL for it. I wouldn't do it from Java either. I'd use sqlplus or whatever. Incidentally, I'm not arguing for 2 tier - rather 3+tier. If you've had trouble with mapping layers, then you're using the wrong software or bad technique. This stuff can and does work when judiciously applied. But you have to know what you're doing when designing the object model. Your statements are somewhat reminiscent of the objects of the anti-garbage collection crowd. Now java has gc and suddenly we're OK with it. Yeah yeah yeah. GC, like OR mapping, can be done well or poorly, but when properly done it outperforms manual memory management - despite the irreational fears of the control freaks that insist you can only get performance with manual memory management. Software design needs to be exactly like architecting a building. The interface points, entry/exits for people, water, electicity, gas, and air need to be well defined, carefully placed (where water and electricity are kept apart, for example) in order for a building to be successful. Good software has to be built the same way. Absolutely agree - but I don't want to have to go to the basement and shovel coal everytime I want the heat adjusted. 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.
Post #48,076 by gdaustin 8/4/02 10:06:51 PM Reply	Average Crud App >For the average crud app, query for a list of objects, do some master-detail >navigation, update or insert some data and save, OR Mapping with lazy faulting >is the only way to fly. But, back in the MS-DOS days there were tools like Clipper which allowed complete idiots to write CRUD apps... My boss at work is intent on proving that hourly people can write CRUD apps in Delphi with minimum help from "real" programmers. Come up with something like "Clipper for Windows" and you can convince management that they don't even need us high cost prima-donnas. Oops, I guess that is MS-Access and VB Office. I think that's the current management phase. Why do we need you $40 an hour (loaded with benefits) prima-donnas when I can get a smart hourly person making $10 - $12 an hour with no benefits use some Clipper or Access tool to build me a database. Seems like I'm wasting a lot of money with you high falutin' "Software Engineers"! My current management's sentiment exactly. I don't want to write CRUD apps for a living. That's why I LIKE writing things like purges on 100 million row databases. Transaction processing/large databases, that's what makes me tick. How do you get 1 million or 10 million transactions a day safely through a set of Unix servers and through a tuned relational database without it dying? >Uh huh. How many apps that the average developer is going to write are going >to do that? Exactly Zero. That's a db maintenance function to be performed by >an administrator and yes you write SQL for it. I wouldn't do it from Java >either. I'd use sqlplus or whatever. Maybe I'm not an average developer, then. I'm probably going exactly where I need to be in working on being a DBA and developing tools for database management and transaction processing. >If you've had trouble with mapping layers, then you're using the wrong >software or bad technique. This stuff can and does work when judiciously >applied. But you have to know what you're doing when designing the object >model. I don't have a problem, because I always make sure I get the database requirements while I'm developing the code. But I've seen a LOT of other people fail, because they assume away WAY too much control to the OO design or structured design tool. >Absolutely agree - but I don't want to have to go to the basement and shovel >coal everytime I want the heat adjusted. If shoveling coal is the fastest way to get the 10 story building from 50 to 75 degrees, then I'm shoveling coal. I agree that the thermostat is nice for regulating heat, but only when it works. Glen Austin
Post #48,094 by tuberculosis 8/5/02 2:43:12 AM Reply	Not like Clipper! Look, I've done clipper programming (a little) and it also exposes and embeds SQL directly in the app which makes the app brittle and sensitive to database changes. It also encourages you to replicate your business logic in the screens. If you read what I wrote on my 2 steps forwards one step back piece I explain this. 2 tier is evil in a multiuser environment. Example - some Sybase consultant thought it would be a good trick to get an organization I was working in hooked on PowerBuilder. So he wrote a little app for service reps to handle some business task. Of course it worked fine for him. Only you get no locking mechanism with these tools. Its just select into a widget, let the user play with the data in the widget, then write code to do updates back to the database based on what changed in the widget. The OR mapping layers do optimistic locking by default. In fact you specify which fields are significant for locking in the model definition. So right there they save you significant work and prevent bugs. As far as getting more done with less - we get a couple of top developers to do the schema and the object model, then get the drones to build UI on top of the business objects. I think you'd prefer to be the developer doing the model (its what I specialize in). Regarding your big operations that have to be done in the database - yes you write stored procs for stuff like that and then expose them as methods in the object model (usually class methods for sweeping stuff like that). Its not a big deal and by putting that api on your database you avoid integrity issues, isolate apps from schema changes, minimize bugs, and still leverage the power of a cast of thousands (of screen painting dolts as management prefers). 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.
Post #48,122 by gdaustin 8/5/02 9:43:52 AM Reply	I'm Amazed that management still thinks there is a "magic bullet". I agree. Doing the schema, the database admin, and the object model is certainly more rewarding than the screens. It's rewarding professionally and it pays better. It just pains me to run into managment (like my current administration), who believes that schemas, administration, and object models aren't important. Then, again, I'm getting paid really well to clean up his prior programmer's Delphi mess. Glen Austin
Post #48,128 by tuberculosis 8/5/02 10:13:18 AM Reply	(Mis)Management Just out of curiosity - how did your management end up management? Whats their background? Career path? Why is that guy in charge and not you? Something about what that guy knows is important to the business owners. Maybe. This is one of the puzzles I'm trying to work out. How come the idiots end up on top? Why are the clueless defining the objectives and the means to reach them in the absence of any real skillset? I wish I knew. 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.
Post #48,139 by gdaustin 8/5/02 10:57:54 AM Reply	Re: (Mis)Management My boss IS the owner of the company. It's a small 50-60 employee company. Glen Austin
Post #48,150 by orion 8/5/02 11:44:01 AM Reply	This is an easy one Either they are a major stock holder, or a friend or relative of one, or the owner of the company. Failing that, they are an employee that worked their way up the ranks by sucking the right dcks, going to happy hour with the other management and getting sht faced, perticipating in spouse-swapping parties, attending those "adult" parties thrown by management (Getting into S&M, hardcore stuff), and bluffing their way into management by pretending that they know what they are doing (The Pointy haired Boss). That is why Idiots end up in management as the majority, they do these things because their job skills suck. They usually have an MBA or something that allows them to get promoted over other coworkers that don't have one. Nobody knows how they were smart enough to get an MBA, it is either fake, or they paid someone to take the classes for them to earn it. Or they were smart at one time, but burned out their brain on drugs after getting the degree? *I am free now, to choose my own destiny.*
Post #48,277 by static 8/5/02 9:45:26 PM Reply	Sales skills. There is a point above most technical positions that require a mix of sales and (people) management skills. Often there is actually a band where the positions also require technical skills. Hence the problems of managers who know enough to be dangerous but not enough to be truly useful. I found the best explanation in, of all places, a Dungeons & Dragons guide about the structure of armies. At the very bottom, you will have Level 0 and Level 1 Fighters. You may have some Level-1 Fighters as Coporals but they'd probably be Level 2 or higher. As you get up towards Generals and Colonels, the levels get higher until you might have a Level 16 Fighter as your army's General. But if they're responsible to a king or prince, you may well have a Level 0 or 1 character as the General or who the General reports to - that's your prince or king. (And their most trusted advisors will be a mix of levels and classes, too.) Quite simply, there is a point where the skillset required changes. In modern large company parlance, when you get to the top of the techs, you have one who is capable of managing other techs. He is not entirely a political animal, but he will play some of it. His boss will be less of a tech, or perhaps a tech with old knowledge, but will be capabe of managing and interacting with other managers who aren't techs. By this level, you find people with sales skills because either the people skills for sales and for management are very similar, or they are similar enough that sales people can learn them better than most. Makes job advancement prospects poor for us techs, though. Wade. "Ah. One of the difficult questions."
Post #48,357 by tuberculosis 8/6/02 10:29:19 AM Reply	Yeah well there's a problem here I got a degree in petroleum engineering. So please bear in mind that I have been trained to bore holes up to 2 miles into the earth, guess how much stuff is down there by sucking carefully on one or two holes in cycles over a couple months, and figure out whether what we've found is gold or dust. One of the more interesting classes was engineering economics. Basically, you're given a set of well test data, and are told to figure out how to maximize the return. You design the production plan, calculate the costs, returns, cash flows, etc. Its all about fiscal responsibility because if your plan is too risky or you don't budget your expenditures you end up sitting on a stack of gold bars too heavy to move. Not very valuable. I think techies - and I know this holds for engineers - have had the business training to manage organizations and large projects effectively. But we're not considered for the roles - even if we lobby for them. Something about a boys club I think. Shared ignorance yields camaraderie. That's what I'm finding. 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.
Post #48,362 by boxley 8/6/02 10:38:34 AM Reply	Fear factor If you have the ability to promote you promote someone you are comfortable with, not nescessarily the one best suited for the job. It is a club in a way so schmoozing is a big part of getting and staying there. thanx, bill ."Once, in the wilds of Afghanistan, I had to subsist on food and water for several weeks." W.C. Fields
Post #48,397 by orion 8/6/02 1:16:50 PM Reply	Yeah sort of like that Norm is a good worker, hard working, honest, and his programs don't see to crash the system. Too bad he doesn't go to Happy Hour with us on Fridays and get sht faced. Now Chris isn't that good of a worker, tends to joke around with the other coworkers a lot, his programs take down servers and are hard to debug. But he gets sht faced with us at Happy Hour. I need to promote one of them to be a Project Leader, but which one? Well I feel more comfortable with Chris than Norman, besides Norman is such a good worker that it is most likely some other firm will hire him away in a year or two anyway. Let's promote Chris instead! *I am free now, to choose my own destiny.*
Post #48,147 by orion 8/5/02 11:36:15 AM Reply	VB can create crud apps too Just ask me about all the VB apps I had to debug for my coworkers that crashed systems. Heck, the ASP apps did it too, only they took down servers. Nothing like spending hours over someone else's code looking for code that causes memory leaks and places they forgot to close off record sets and set objects back into nothing to free up memory. Also managled up HTML parsing in ASP was a loser as well. They kept these people but got rid of me? WTF? *I am free now, to choose my own destiny.*
Post #48,154 by admin 8/5/02 12:01:44 PM Reply	Wrong crud... CRUD == Create Read Update Delete Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #48,025 by bluke 8/4/02 9:57:18 AM Reply	I also hate Java ... and I have been paying the bills with it for the past 5 years and I work at a company that is heavily invested in Java. Java is the Windows of programming languages. It looks nice but when you actually try to use it seriously it sucks. The Java type system is a joke, they still haven't delivered generics, and you can forget about them ever dealing with the primitive-object inconsistencies. The development model is still in the dark ages, with files, compile, deploy cycle, etc. With an OO language why are developers dealing with files and classpaths, etc. there should be a higher level abstraction (something like VA Java taken from Smalltalk) I come from a Smalltalk background, and when I look at the elegance of Smalltalk and compare it to Java, it makes me sick. The Java solution for so many problems is code generation. For example, the need for something like closures (blocks in Smalltalk) resulted in inner classes (not nearly as useful as Smalltalk blocks and much uglier) which are just a compiler trick. The upcoming generics support will again be a compiler trick, where the compiler will "magically" generate all the casts for you, whoopee. Java has contributed little or nothing original, it has taken bits and pieces from different places, unfortunately the wrong bits and pieces.
Post #48,034 by deSitter 8/4/02 11:10:03 AM Reply	Re: I also hate Java ... Java may be popular because the mediocre can hide out in it. I remember last year my officemate had an slow DB access problem. I told him I knew someone in Detroit who knew how to do things right - so we got on chat through IWETHEY and Scott pointed out all the wrong things to do - the very things this guy was doing. Now, my officemate seemded more than anything, scared (I was grinning with glee myself). He wasn't at all appreciative. He was more interested in his H1B status and buying expensive electronics. I'm so glad I don't have to deal with Java. -drl
Post #48,051 by tuberculosis 8/4/02 4:02:46 PM Reply	Blanchard's Law When code generation arises as a routine technique, it means your language lacks sufficient power of expression for coping with your problem domain. Corollary: Code generation should (almost) never be necessary in any sufficiently advanced programming environment. 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.
Post #48,272 by wharris2 8/5/02 9:30:54 PM Reply	Hate Java? I don't hate Java. I hate what Sun has done with Java. I've stopped bothering looking at the "bug list" on their Java site; doesn't do any good to vote up a bug for consideration anyway, does it? They'll just roll out another API of the week (likely as full of bugs as the last API) and close the bug report until someone submits a new bug report, which more than likely will be closed because it was fixed (not!) by the new API. Java applets, at the beginning, were an exciting concept. When it became evident that most implementations (including Sun's) were buggy as hell, somehow the emphesis changed to Java Enterprise (never mind all the useful stuff that might have been done with application Java). Except for its problems, Java Enterprise has been relatively successful. But on a much more limited scale, not the all-encompassing write-once run-anywhere stuff originally envisioned for Java. All in all, I'd rather program for fun and profit in Delphi even though I dislike Pascal. The lawyers would mostly rather be what they are than get out of the way even if the cost was Hammerfall. - Jerry Pournelle
Post #48,683 by bluke 8/8/02 11:17:52 AM Reply	I hate Java because of what it represents namely the triumph of junk through marketing over technical excellence. Java is a bunch of ideas taken from other languages cobbled together. Java was designed by people who had a very narrow viewpoint, namely C, C++, and Objective C. How could you design a language in the 1990's and not build in some form of Generic types? How could you build such a brain dead type system? Why primitive types? I could go one forever. Java 1.0 was absolutely useless. Here are some of the shortcomings that I can think of off the top of my head: 1. Idiotic event model (had to be changed in 1.1) 2. No reflection (had to be added in 1.1) 3. primitive types (which only gets worse when you add in reflection (which doesn't work well with primitive types), collections, and generics )see this link for a great paper on why primitive types are so bad [link\|http://www7.software.ibm.com/vad.nsf/Data/Document2712\|http://www7.softwar...Document2712] ) 4. No generics 5. No easy way to do proxies 6. no collections 7. No control over garbage collector (a little better now with Weak References) Based on this Java 1.0 was basically useless and should have been stillborn. However, the marketing machine is king and it didn't matter. Here is a great quote from one of the Java newsgroups: "The Java-Language-Design Research Algorithm, Unleashed: if (objective-C shows a way to do things better than C++) \t do that; else if (we really really hate this thing as C++ does it) \t/* do nothing */; else \tc++.copy_from_slavishly_without_much_more_thought; " For just about every feature that Java has you can find a better idea somewhere else. Just like Windows dominates the desktop even though it is a piece of junk, Java is dominating the programming language space even though it is a piece of junk. If I sound bitter it's because I am. I was a Smalltalk developer from 94-97 and absolutely loved the language, and now basically Java has killed Smalltalk. I have found many Java developers who would prefer to develop in another language (such as Smalltalk) if they could, I have not found any Smalltalk developers who prefer Java. It pains me greatly when I think of how much better things would be if Smalltalk had become the dominant language instead of Java.
Post #48,695 by tseliot 8/8/02 2:15:01 PM Reply	I have to agree. I hate the marketing hype. But for writing web-enabled business apps, it's a great tool, mostly because my HTML/JSP guy doesn't have to learn full-blown Java to get a benefit. Finisterre said that while he wanted to resolve the dispute with HP, he resented receiving DMCA threats. "We are like the guys that found out that Firestone tires have issues on Ford explorers," he said. "It's not our fault your Explorer has crap tires. We just pointed it out. We should not get attacked for pointing out issues in someone\ufffds product nor for proving it is possible." Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10

Welcome to IWETHEY!