User loginNavigation |
ScalabilityFrom Yearning for a practical scheme - "I don't want to load a SRFI I do wonder about the scalability of CL or Scheme along the number-of-coders axis. When you have 20+ programmers working on code that was originally written by a separate group of 20+ programmers... The limitations of a language like Java might actually be a benefit in these This is an issue close to my heart, and one that I think the LtU under-discusses. First of all, a few confessions: I am a Haskell afficionado, and hate Java with a passion for the mindset that it promotes, where coders become nothing more than LoC mincers. It saddens and angers me that people are wasting time learning it, because there is nothing in Java (or C#) that is new; and old in them are botched and bungled. That said, however, I have started to appreciate them in a different capacity. I've recently started a position with as a lead and architect, and so also manager. After floundering for a bit, I started to think like a manager (much to my regret). The business reality is that most "programmers" (and I use the term loosely) are not LtU material. They probably didn't see the symbol lambda during their university educations. Furthermore, asking them to understand the intricacies of CPS transforms and endo-hylo-cata-ana-expi-ali-docious morphims. They wouldn't be interested either. Most programmers are just Java monkeys; it arises from the fact that there are more people than can competently (by our standards) program who are willing to take the salaries that the industry offers. Doubtlessly, if they did not work in the industry, the industry as a whole would produce better work (though not more work; more on this in a minute). The wages would also be higher... which would then attract them right back. The fact is that we count competence in terms of elegance and a feeling that a piece of code will last -- a Mona Lisa of the pyramids. The customers of our industry, however, does not hold us to such high standards. They are happy to spend less time looking for their data. They are really happy when you can save them even the smallest bit of time. They will also be satisfied with a poorly written piece of shit that passes the basic mustard. This is the reality, and no amount of Mary Poppins impressions will change that. These problems plague all fields, engineering especially. There is one main aspect in which we stand out, which is that we deal with more complexity than any other field. Other industries struggle with structure more than 20 or 30 layers deep, while we brush them off and imagine towers so tall that we can't imagine any further. We then build them, and see how we can build even taller. I estimate (also known as pulling numbers outta my ass) that we deal with 100 times more layers of structure than any other field. In a way, it can be said that software engineering is all about complexity management. Which brings me back to Java. It, as a language, sucks. Its one redeeming feature is that it is a lowest common denominator. I could get my English majoring friend to learn it. At first glance, the language itself is poor as hell to manage complexity. Surely the fact that you need tens of files just to equal a page of Haskell already represents a huge LoC count? Not to mention readability? Yes, in my opinion. But that's also not where Java shines. Indeed, Java is less about programming and libraries and so on, and more about the processes which are built around them. Everything from the consistency of presentation of documentation to universality of training schemes that exist. These are extra-language features that have made it popular. It is also, AFAICK, the first language that was commercially pushed successfully. These things we cannot ignore. The first lesson that I learnt doing project management, is that a project is less about the technologies, even less about the product, and almost all about the team. The people that make up the project are the project. If you are lucky that you've got a crack team of PL specialists and who are also experts in the problem domain, then you will succeed. But you're never going to get that. At best, you will get 10 Java monkey level people, and 1 who can grok the difference between structure subtyping and nominal subtyping (not in those words, however). This is where the Java processes become invaluable -- they've laid out all the correct procedures that you, as the lead, should do to get everyone to work together. You draw some UML diagrams, etc and just generally follow the road. At the end of the day, if it fails, you can simply say that as an industry, you weren't ready to take on the challenge, and be absolved of personal responsibility. Furthermore, it also helps you with planning -- how many packages, how many components, how many classes == how many man-hours == easy calculation of projected costs and timescale. These are the things that the customers care about, and it is a rare customer that cares even about "maintainance" costs, where you'd have some leeway to build in some reason to sneaky something good in. Oh, and the worst thing is that most won't even care about that -- they'll ask about risk, which forces you to justify any and all choices, especially ones perceived by the local "expert" as outliers. On these fronts, Java stands unrivalled (except for C#, which for the moment is almost the exact same). It makes economic sense. It also makes no sense in any other way. If I get a Lisp guru to hack up some code, the resulting poetry will be unutterably beautiful, and will take another equal guru forever to read it, all the while exclaming the great use of macro transformers. It becomes a single person pursuit. There is nothing wrong in general with single person endevours, but there are times when you need to get something done quicker than one person can, and then you need more people to help. Thus we are back at the beginning. We have unimaginable complexity, and we have people who can't comprehend it. We do need formal processes to help us. So far, the only successful industrial scale ones have been extra-language. I wonder if it would be possible to bring them into the language? In other words, to have the language incorporate a framework to help with the workflow? I've personally tried to control the complexity by using industry standard protocols to set out the edges of components and hoping that each component can be done by one person. I have a feeling that there is always going to be a gap between those who can see the system in the whole, and those who will be working the trenches; I also find it unsatisfactory. I also don't have any better ideas. By genneth at 2005-10-06 19:50 | LtU Forum | previous forum topic | next forum topic | other blogs | 16459 reads
|
Browse archives
Active forum topics |
Recent comments
16 weeks 1 day ago
16 weeks 1 day ago
16 weeks 1 day ago
38 weeks 2 days ago
42 weeks 4 days ago
44 weeks 1 day ago
44 weeks 1 day ago
46 weeks 6 days ago
51 weeks 4 days ago
51 weeks 4 days ago