On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote: > Perl is certainly not a good language to learn as a beginner. Most Perl > code you will find is obfuscated, as Perl syntax promotes obfuscation.
This is nonsense. Please present some evidence to back up your claims.
Dave...
-- It was long ago and it was far away And it was so much better that it is today
"Wade Humeniuk" <w...@nospam.nowhere> wrote in message <news:pL8h9.3771$6L6.386782@news1.telusplanet.net>... > "Alec" <alec2...@ziplip.com> wrote in message > news:f2da8e5d.0209151144.20138358@posting.google.com... > > otmorozok1...@yahoo.com (Scott) wrote in message > <news:b5a31bec.0209142220.222332fd@posting.google.com>... > > Many people expected a lot from Lisp, and given your background in > > Scheme, Lisp would seem like a reasonable next step. The industry > > realized over the years that while Lisp makes a fine language for > > certain niche small to medium size projects, it has two serious > > drawbacks: firstly, maintainability issues arise, because Lisp > > programmers can never understand each other's code, and secondly, Lisp > > teaches you bad programming style, as your code is usually a mess of > > if's, conds, and so on. That is why it almost lost its relevance by > > now. I can not say that I'm glad, because a lof of my own expertise is > > wasted. Oh well, that's life.
> Many people expect a lot out of C++, and given your background in Scheme, C++ > would be seem like a reasonable next step. The industry realized over the > decade that while C++ makes a fine language for certain small to medium size > projects, it has two serious drawbacks: firstly, maintainalbility issues arise, > because C++ programmers can never understand each other's code and class > heiacrchies, and secondly, C++ teaches and encourages one and only one bad > programming style, as your code is usually a mess of if's, for's, function > calls, include files, overloaded operators and so on. That is why it it losing > its relevance. I can say that I'm glad, because I have not wasted a lot of my > expertise on it. Thank God that's life.
Wade, thanks for attempting to be funny and for sharing with us your dilettante opinion, of course. Since, as you mentioned yourself, you have not spent a lot of time on C++, what makes you think you are even remotely capable of judging it: what exactly have you "learned" about it? I suspect you are simply repeating whatever FUD you have heard or read. Do not let slashcrap and similar sources do your thinking for you.
> > I was one of the early adopters when C++ came out (C with classes), > > and I'm still very fond of it. I think the standardization committee > > and Bjarnee have done a wonderful job. C++, of course has its own > > drawbacks, the most important of which being that you must not be a > > half-wit if you want to learn to use it correctly. If you lack in the > > brains department, you can still make a decent living as a programmer > > coding in shite like Java or VB.
> > So it all depends on your own mental abilities and on your dedication
All the above comments are very fair points. I think he should maybe come back to it though once he has his feet planted in a decent high level language
> Many people expected a lot from Lisp, and given your background in > Scheme, Lisp would seem like a reasonable next step. The industry > realized over the years that while Lisp makes a fine language for > certain niche small to medium size projects, it has two serious > drawbacks: firstly, maintainability issues arise, because Lisp > programmers can never understand each other's code, and secondly, Lisp > teaches you bad programming style, as your code is usually a mess of > if's, conds, and so on. That is why it almost lost its relevance by > now. I can not say that I'm glad, because a lof of my own expertise is > wasted. Oh well, that's life.
Could you please be more specific about the maintainability issues and bad programming style? Perhaps you could give a few examples?
Regards, Richard
-- Richard Krushelnitskiy "I know not with what weapons World War III will rkrush (at) gmx.net be fought, but World War IV will be fought with http://rkrush.cjb.net sticks and stones." -- Albert Einstein
> > As someone correctly mentioned you should certainly stay from hype > > languages like Java, Perl, etc.
> Excuse me, I don't want to start a flame war but, under what definition > of hype are you using to define Perl?
> John
When I say "hype" languages, I am not merely referring to languages that are popular, but those that are at the same time mediocre or bad. For them, popularity comes from aggressive marketing, etc. In case of Java, it was Sun's desire to take a bite of Microsoft's market, and in case of Perl, it was a bunch of things, not the least of which was OReilly of course. If it were up to them, they would be feeding us new revolutionary "tech" every month.
* otmorozok1...@yahoo.com (Scott) | Another friend tells me "define what you mean by 'better programmer'".
You have received much advice, most of which I find useful given a prior understanding of what it means to be a programmer, but it occurs to me that this is far from as obvious as one might think. What kinds of things would you like the computer to do for you? What kinds of things are you already good enough at that you can teach a computer to do it? Do you have extensive experience with hardware so you want to control devices and do things like play music or movies and such? Are you adept at human-computer interaction so you want to write software that embodies your psychological insight to write software that makes a human being more efficient at some task? Have you succeeded in teaching children or adults anything and would like to write computer-aided teaching software? Do you enjoy graphic arts and typography and would like to use the computer to automate the production of, say, flyers and posters? Are you interested in photography and would like to write software for digital image processing? Is optical recognition and artificial vision on your list of interests? The list of questions obviously goes on and on, extending into every field of human endeavors.
In my view, to be a programmer is to be sufficiently well versed in some non- computer-related field that you can see how the computer can aid practioners of that field accomplish their goals. Many programmers never progress beyond the point of aiding their own use of the computer and never do anything "real" -- the number of software packages that help people read mail and news and waste enormous amount of time in front of the computer are legion, but they tend to make people spend /more/ time on these tasks than they would or should have done compared to actually productive tasks.
Take spam, for instance. Varying amounts of effort by an enormous number of people have been poured into getting rid of this problem, including many pretty clever filtering tricks. However, the opportunity arises for machine recognition of meaning in electronic texts such that computers can analyze and classify them according to, say, Dewey's or Universal decimal classification. If this problem was solved, such things as the Semantic Web and search engines that produced topic maps would provide vastly different perspectives on the enormous emount of web pages out there. Spam detection would fall out of this work simply by being classified in areas most people have no interest, and if you should be interested in some of the things that are advertised by this means, you would be able to locate it. Imagine a world in which you could ask your computer to retrieve news articles and web pages according to a semantic classification instead of having to try out different search words. Imagine that this classification would not need a human to classify the documents but where machines would "understand" them. What would you need to know as a programmer before you could successfully implement something like this? Clearly, being a good programmer, you would need to know many algorithms in addition to understanding the nature of classification better than most of the people who do it by hand, perhaps instead writing a system that finds patterns in what has already been classified instead of actually understanding things.
Often, a the solution to a problem is very different from the solutions that come to mind immediately. High intelligence and good creativity is needed atop a vast mass of knowledge from many fields is necessary to solve the many remaining interesting problems.
However, if all it means to be a programmer is to be able to code up something from a specification and a design provided by others, "all" you need is a good command of the tools you use and the language grammar and idioms to express the ideas that somebody else have dreamt up. This part of programming is not the most interesting in my view, but many people who hire programmers want them to think as little as possible and be as faithful as possible to designs made by others. To be a "better" programmer in this regard is very different from a better programmer who can solve unsolved problems.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
On Mon, 16 Sep 2002 04:49:08 -0300, Erik Naggum wrote:
> Take spam, for instance. Varying amounts of effort by an enormous > number of people have been poured into getting rid of this problem, > including many pretty clever filtering tricks. However, the > opportunity arises for machine recognition of meaning in electronic > texts such that computers can analyze and classify them according to, > say, Dewey's or Universal decimal classification. If this problem was > solved, such things as the Semantic Web and search engines that > produced topic maps would provide vastly different perspectives on the > enormous emount of web pages out there. Spam detection would fall out > of this work simply by being classified in areas most people have no > interest, and if you should be interested in some of the things that > are advertised by this means, you would be able to locate it. Imagine > a world in which you could ask your computer to retrieve news articles > and web pages according to a semantic classification instead of having > to try out different search words. Imagine that this classification > would not need a human to classify the documents but where machines > would "understand" them. What would you need to know as a programmer > before you could successfully implement something like this? Clearly, > being a good programmer, you would need to know many algorithms in > addition to understanding the nature of classification better than > most of the people who do it by hand, perhaps instead writing a system > that finds patterns in what has already been classified instead of > actually understanding things.
Dear Mr. Naggum --
I don't understand your point of view, in the light of the fact that a couple of weeks ago you said that SGML and XML were "braindead." That really kept me wondering for days...I kept thinking "well, how would you view, then, a thing like the Semantic Web from a Lisp perspective?" I thought it would be, perhaps, something like the LispWeb server, which seemed a very "intelligent" proposal (if I may make a pun with the A.I. feature.) Now, you're a "senior" member of this community, and I respect what you write and have often learned a lot from you posts and interesting views of issues posted here. That said... Would you care to expand on your views regarding the Semantic Web, XML being "hopeless", SGML being "braindead" and all that in what regards a Lisp approach to those important questions? That is, how would *you* go about it, if I may ask? All these things matter a lot to me, being from the medical community, and quite aware of the importance that being able to integrate the data that continues to grow at exponential rate in the field (genome, for instance, the barrier that tradional statistics methods are up against in a large medical database, etc...)
> > So, one of my friends tells me that I should learn C++, because "it's > > the best". But, seriously, he doesn't know anything but C++, so I'm
> I've used C++ since the 1980's, and I prefer other languages, such as > Smalltalk and Common Lisp. My personal preference is Common Lisp, but > it takes a long time for most programmers to learn it fluently. What > I like about it is that I can program much faster in it than in other
Greetings, Scavenger. With all due respect to another veteran, I have to disagree with you regarding Lisp. While you're not blatantly recommending it to newbies, you are being very suggestive in your tone. Time is money, and time spent learning Lisp could be better spent more productively elsewhere. And this is coming from someone who has worked with Lisp 2 through Common Lisp for years in several teams and solo. Besides, he already knows some Scheme, which diminishes the educational value of Lisp for him even further. In any event, what was the largest Lisp team that you have ever worked in? What is the largest Lisp team that you have ever heard of that actually managed to deploy their product successfully? Orbitz is more of an exception than a rule. Most large team efforts in Lisp were failures, and that's a fact. IIRC the notorious "Mythical Man-Month" might have even mentioned this curious fact, although I may be confusing it with another book.
> On the other hand, what's best for a novice? I think it depends on > your personality and talent more than anything else. Do you need > something that will keep you constantly motivated, or are you > self-motivated to learn more faster regardless of immediate feedback? > Nobody but you can really know the answers to such questions. You > have to know yourself, and seek out something that fits you like a > glove. Other people's advice is based on their own experience in the > context of their own talents and motivations. And for those who need > constant positive feedback, there are different kinds of feedback, > fitting different personalities different ways. For example, do you > need to build a GUI and see it work while you add your program's > features while learning how to use your programming language? Or do > you prefer to use a workspace paradigm where you can test small > snippets of code easily and see the results of those immediately > without putting them in the context of a larger program? And what > about money? Some people can only learn on the job, because their > personality won't let them spend time doing something they aren't > getting paid for. And some just need the constant feeling that the > work they're doing will soon result in more money for them, such as > when they're working towards an advanced degree and are getting good > grades constantly, and knowing they will be able to get a good job as > a result. This is the kind of stuff you have to know about yourself, > as well as a lot of other aspects, such as how well you learn at > different levels of abstraction, etc.
>> I need your advice! Last summer I took an introductory programming >> course and learned a little bit of Scheme, even tho I didn't like it >> too much...
>> HOwever, I realized that I want to be better at this stuff and learn >> more about programming. It's fascinating. I talked to some of my >> friedns and told them that I want to be a better programmer. I'm >> thinking of learning a new programming language, but I do not know >> which. Basically, I do not particularly care about the details, such >> as if a language is windows-only. What I do care about is learning >> something new.
>To learn you have to start where you are at. You already know some Scheme, so >what I would suggest is to program some non-trivial application in Scheme. My >first suggestion is to write a web-server (as the www is all the rage these >days). Give yourself a deadline, say 30 days, and get at it. If you have any >problems just ask for help in these forums (or just comp.lang.scheme). Post >your code for critical review (put a copyright on it).
>After this brief excursion you will better understand what is needed in a >programing language and then you can pick your next application and programming >language. Repeat the procedure, continue until happy.
>See you in 30 days.....
A server is too complex and vague a task. The vagueness comes from what functionality you want to add. Do you support CGI and virtual servers for example? The complexity comes from serveral fronts, mainly the complexity of HTTP itself ( which is not that complex, but more complex than for one junior programmer ).
Instead go to: http://icfpcontest.cse.ogi.edu/ there you will find 5 problems doable by one programmer that are extremely well defined and should be doable by one person in 30 days.
Thome and Hunt ( aka the pragmatic programmers ) advocate a practice called loty ( language of the year ) where a person learns a new language each year. Recently I've begun to advocate starting your loty on Labor day, and using the exam as your "final exam" of the last years loty, and using the exam as a problem to probe next years loty.
* alec2001 wrote: > Most large team efforts in Lisp were failures, and that's a > fact. IIRC the notorious "Mythical Man-Month" might have even > mentioned this curious fact, although I may be confusing it with > another book.
Most large-team software efforts are failures, full stop.
The book you are referring to is probably `software runaways' by someone-or-other which is a collection of papers describing various software project catastrophes. It has a chapter the failure of a project at MCC and blaming it on Lisp. This is, essentially, bullshit - there ware a lot of other problems which caused this disaster. I suspect that many of its other papers are also bullshit although I haven't checked up on them.
Here's a description from someone who was there (you can probably find this by searching on google groups, although I have it in a file with no reference, sorry).
A dozen years later, that BS paper still gets my blood boiling! Lisp was NOT MCC's problem. Incompetent management was! The director of the CAD group kept overriding the system architect and made technical decisions about which he knew nothing. His constant interference completely underminded any chance of it being a success. As a result of his interference, each group leader went and did their own thing, giving no consideration to the overall goals. As an example of how disfunctional management became, I and another engineer attended a meeting with the director and the system architect to discuss design size problems, namely that TI and LMI lisp machines didn't have enough address space to handle the size of problems that MCC wanted. (Not without doing software "overlays".) Half way thru the meeting, the director was sitting in one corner staring out the window and the system architect was sitting in the opposite corner staring out that window. The director just didn't want to hear about any problems with the TIs and LMIs. Or anything else! It become clear to me at that moment that MCC was doomed to failure because of the internal politics and incompetence of management.
ALthough I didn't always agree with the decisions of the system architect (more often than not, I disagreed!), I knew that for a large system to have any hope of success, one person had to be responsible for the global design. Due to the director at MCC CAD, there was no ONE person responsible for the system design. Well, that's not quite true. The system architect WAS responsible for the design. He just had no authority to carry it out.
I know of no real evidence that large Lisp systems have worse problems than large systems in any other languages. Since Lisp is a left-field choice it's a fairly obvious candidate for blame when large software projects screw up - better to blame the language than the mismanagement if you want to keep your job, and, like buying IBM, no-one ever gets sacked for choosing C++ or Java.
Erik Naggum <e...@naggum.no> writes: > * otmorozok1...@yahoo.com (Scott) > | Another friend tells me "define what you mean by 'better programmer'".
[ ... ]
> However, if all it means to be a programmer is to be able to code up something > from a specification and a design provided by others, "all" you need is a good > command of the tools you use and the language grammar and idioms to express > the ideas that somebody else have dreamt up. This part of programming is not > the most interesting in my view, but many people who hire programmers want > them to think as little as possible and be as faithful as possible to designs > made by others. To be a "better" programmer in this regard is very different > from a better programmer who can solve unsolved problems.
Another way to look at what makes a better programmer is by looking at the endpoints, i.e. the best and worst possibilities. To me, the closest I can come to the endpoints are these:
- Most elemental programmer: I don't consider a person who learns to use a word-processor (or any other shrink-wrapped app, for that matter) a programmer. However, if that app has a preferences option, and the user is using it to customize the app for their own usages, well that becomes programming. Some may argue that this is not really programming, because it is so common, but then where else would we draw the line?
- The Ultimate Programmer: I saw an original Star Trek episode, when it first came out, and as I recall (but it may be fuzzy) Kirk and Spock break into an ancient computer room, and find a computer not built by any Federation life forms. Spock had never seen the computer, but proceeds to discover what it is (I think it was an archive library of some sort) and then to access the data, so that their adventure could go on. Being fairly new to programming at the time, and having seen several completely different languages, operating systems, and even I/O devices, I scoffed at this episode at first; I didn't think it was possible to encounter a completely foreign computer and figure out how to access it, let alone work it. But now that I am more experienced, I believe (without proof) that it is possible, although I still admire the scientific and programming expertise of Spock to be able to figure it out so quickly.
* synthespian | I don't understand your point of view, in the light of the fact that a | couple of weeks ago you said that SGML and XML were "braindead."
Well, let me put it this way: The XML crowd believes that if you only add enough markup, everything humankind has ever dreamt of will suddenly emerge from the chaos. I believe that this is a very serious misunderstanding of both chaos and emergent properties and that more markup will, in fact, prevent them from emerging. XML-style markup effectively prohibits the multiple perspectives on the same information that makes it usable for multiple purposes. In this sense, the more you employ XML to achieve your goals, the more irrelevant the result will become.
| That really kept me wondering for days...I kept thinking "well, how would | you view, then, a thing like the Semantic Web from a Lisp perspective?"
Note that the Semantic Web so far is being realized with tons and tons of markup that fail miserably in being the flexible declarative language to describe semantics in web pages that we need. I consider the efforts by the people who work on this without any understanding of how people have dealt with semantic classification of information prior to the Internet to be a colossal waste of effort. They will, in all likelihood, reinvent everything badly, being more interested in concocting useless syntactic monsters than the information infrastructure that is necessary to realize their ideas.
| Would you care to expand on your views regarding the Semantic Web, XML being | "hopeless", SGML being "braindead" and all that in what regards a Lisp | approach to those important questions? That is, how would *you* go about | it, if I may ask?
This is a very broad question. I think the Semantic Web will be realized when the analytical capacity of software has progressed to the point where people are actively encouraged to help the computer by communicating their intent and our human-computer-human communication changes out language and our communication skills. For instance, when it becomes rewarding for the user to make the steps of his argument clear to the computer so the computer can help him communicate with other computers that might more effectively argue his point with the originating human who will listen more to his computer than to other people, the user will benefit from communicating in a way that removes much of the ambiguity of our current language. This will not happen if the amount of work necessary to communicate with the computer is as immensely complicated as the current XML-based Semantic Web.
| All these things matter a lot to me, being from the medical community, and | quite aware of the importance that being able to integrate the data that | continues to grow at exponential rate in the field (genome, for instance, | the barrier that tradional statistics methods are up against in a large | medical database, etc...)
I envision a future where people are sufficiently encouraged by computers to learn the skills of rhetoric, argumentation, and logic to actually achieve what education cannot achieve when there is no clear benefit to learning either of these skills. I also believe that something like Dewey's or the Universal decimal classification system needs to be taught as the optimal means of searching for information with computers. (The actual numbers is not the point -- the hierarchical structuring of human knowledge that is embodied in the coding into numbers is an unparallelled achievement. The silly re-invention of "ontologies" in the Semantic Web context is pathetic in comparison.) All of this actually means that philosophy, epistemology, the nature of concepts, etc, will have to become fundamental in people's approach to information. Today, we are hampered by many false starts in these areas and much muddled thinking and expression thereof. I believe that over time, probably many decades, perhaps even centuries, we will get rid of many of the historical accidents in our language and communication and will consider the new accident of using computers a more fundamental property than it is today. When you cannot get anything /done/ being sloppy and incoherent, people will just adapt. The school that says that computers should adapt to people is wrong for many reasons, the most important of which is the misguided notion that what people do today is better than whet they will do tomorrow under new technological influences, that yesterday's (or yestercentury's) technology that shaped our language and thinking, is better than our current or future technology, is keeping us all back.
I am, obviously, not advocating that we go into some "logical" language or that we "speak mathematics" (frequent hysterical rejections of improvements in human communication usually take this form by mathofobes), but that we consider the benefits that befall us when adapting our natural language to the requirements that follow from wanting to get the most out of exchanges with our communication peers. When our peers become computers, as the Semantic Web clearly foresee, people should, indeed must, change to make themselves better understood and the exchange more fruitful for all parties.
If the Sapir-Whorf hypothesis holds, we must change our language in order to become more "rational" vis-a-vis the computer. This could become a "class distinction" in the future, where the educated communicate mostly with their computers and the illiterate mostly with people. It is at times like this that my desire to see immortality in our lifetime just gets more intense.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
On Sep 16, Kenny Chaffin inscribed on the eternal scroll:
> d...@dave.org.uk says... > > On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
> > > Perl is certainly not a good language to learn as a beginner.
petitio principii
> > > Most Perl > > > code you will find is obfuscated, as Perl syntax promotes obfuscation.
> > This is nonsense. Please present some evidence to back up your claims.
> check out the obfuscated perl contest....
Why? If "most Perl code" was obfuscated, there would be no point in holding a contest. The exception proves the rule.
Perl is certainly _capable_ of being used to write well-structured and transparent code. As far as learning a language is concerned, surely that is the key, rather than bandying dubious statistics about its users, many of whom - present company excepted, of course - appear to me to be writing FORTRAN in Perl4 -- but then, "physicists write FORTRAN in any language" (attribution not known, but heard quoted at CERN many years ago).
On Sun, 15 Sep 2002 18:43:25 -0400, "Scott Palmer"
<Scott.Pal...@sympatico.ca> wrote: >Perl is certainly not a good language to learn as a beginner.
Yes it is. It is a very easy language for beginners to learn. You can accomplish a lot of useful tasks knowing only a few functions. It has the best and least obfuscated documentation system (perldoc) I have seen in a programming language, by far the best system for sharing reusable code (CPAN) and many other features.
>Most Perl code you will find is obfuscated, as Perl syntax >promotes obfuscation.
No it doesn't. A bad programmer can write obfuscated code in any language. Good Perl code is as clear as anything in existence.
-- Regards, Helgi Briem helgi AT decode DOT is
A: Top posting Q: What is the most irritating thing on Usenet? - "Gordon" on apihna
> In article <pan.2002.09.16.05.53.58.131460.13...@dave.org.uk>, > d...@dave.org.uk says... >> On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
>> > Perl is certainly not a good language to learn as a beginner. Most Perl >> > code you will find is obfuscated, as Perl syntax promotes obfuscation.
>> This is nonsense. Please present some evidence to back up your claims. > check out the obfuscated perl contest....
Eh? Just because a thing like the OPC is feasible in a language doesn't mean it is its only way of writing code. I suggest you go to http://search.cpan.org/, pick up a random module and view the corresponding source.
And if you think that Perl promotes obfuscation, why not come up with a piece of real obfuscated Perl code? You'll realize that it's not that easy to do it 'properly', that's why an OPC and also Perl Golf can exist.
* "Alan J. Flavell" <flav...@mail.cern.ch> | Why? If "most Perl code" was obfuscated, there would be no point in | holding a contest. The exception proves the rule.
Since you bring this age-old expression up, perhaps you should know what it really means to those few who know what it really means. From The Concise Oxford Dictionary of Proverbs, Oxford University Press 1998, Oxford Reference Online, 16 SEPT 2002 (they make me say all this, sorry)
The very fact of an exception proves there must be a rule? (Brewer); now frequently misunderstood and used to justify inconsistency. Cf. L. exceptio probat regulam in casibus non exceptis, the exception confirms the rule in cases not excepted.
This URL is also a required part of the reference, but it appears not to work unless you are a subscriber. Oh, well, for the IP lawyers, then:
I have been prgramming 30+ years and agree with this! I'd like to add Forth to the language list here. Haven't used it for years, but it taught me how to factor an application/system/program to the proper pieces!!! I am sure that my coding style for every programming language I have learned since then is influenced by what I learned in programming Forth!
Also, there is a long out of print book called "Thinking Forth" that would be an all time computer science classid if it had been written about C (same time period). If you can get past the Forth examples, it will teach you a lot about system design!!!
Pascal Costanza <costa...@web.de> wrote in message <news:3D847CC5.2050406@web.de>... > Eric J. Roode wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1
> >>HOwever, I realized that I want to be better at this stuff and learn > >>more about programming. It's fascinating. I talked to some of my > >>friedns and told them that I want to be a better programmer. I'm > >>thinking of learning a new programming language, but I do not know > >>which.
> > ...
> >>Thanks in advance for your time...
> > In my opinion, you should learn MANY languages. You won't necessarily > > use then, and don't learn them all at once (that's confusing), but > > knowing how different languages approach similar problems, and knowing > > the strengths and weaknesses of various languages, is an excellent way to > > become a better programmer.
> I totally agree and want to add that you should make sure to not only > learn different languages but also languages from different programming > paradigms. Different problems need different approaches, and to know > different approaches means to be able to solve more problems adequately.
> Some other languages allow to you to mix various paradigms: C++, Common > Lisp, Objective CAML, Python, Leda
> Also make sure in the long run that you get to know both dynamically > typed (for example Scheme, Lisp, Smalltalk) and statically typed > languages (for example Haskell, gbeta, CAML, Java).
> (I have definitely forgotten some, and the categorization is surely not > exhaustive.)
> It will take you a while to become a really good programmer but it's > worth it. There's no general recommendation which language to start > with, just go with your gut feelings. There is no single "best" > language, all have their different tradeoffs and resolve different sets > of forces. And don't believe in hype: current trendy languages are not > necessarily good languages to start with with regard to the learning > perspective. (However, it might be good for economical reasons to > include them in the long run. ;)
> Wade, thanks for attempting to be funny and for sharing with us your > dilettante opinion, of course. Since, as you mentioned yourself, you > have not spent a lot of time on C++, what makes you think you are even > remotely capable of judging it: what exactly have you "learned" about > it? I suspect you are simply repeating whatever FUD you have heard or > read. Do not let slashcrap and similar sources do your thinking for > you.
I have 5 years experience with C++. Using one of the very first beta compilers from DEC. I think the years were from 1993-1998. I do not consider this a lot of time ( I have been programming since 1977). The largest programming project I have worked on involved 85 people with the C++ team consisting of 5 programmers (it was experimental at the time).
Mostly what I learned from the language is that programmers using C++ attempt to force the understanding of the world into the OO paradigm. They also attempt to use all the OO features of the C++ language (inheritence, multiple inheritence, overloading) and this just slows down the whole development effort. It also results in tons of useless code that basically does nothing. All the code that really implements functionality is bound into a few key functions. Also I have found that programming teams spend in inordinate amount of time "talking" about the design and not enough "doing" the work. Its like people feel they are actually accomplishing something, but one does not truly understand the problem until one writes the code. In some ways getting the coding (a truly technical specification) done will facilitate getting the design done.
As with most languages like C/C++/Pascal/Compile-Link-Test-Languages great amounts of test scafolding (unit testing and intergration testing) programs have to be written, which in a substantive testing environment, exceeds the actual code written. For larger and larger projects this can be the kiss of death since the test code is always more complex than the actual tested code. Much of the time people also resort to scripting languages to do the testing as the underlying language is not expressive enough.
I have mostly given them all up to develop in Common Lisp where multiple programming styles are supported, test code is integrated with the development environment (the test script language is also in CL) and all in all I am many times more productive. Unit testing is a snap in CL and integration testing is in some ways is an expanded form of unit testing.
Kenny Tilton <ktil...@nyc.rr.com> wrote in message <news:3D853072.4030006@nyc.rr.com>... > i did not like it either. nothing interesting. threw it in the garbage. > if only i could learn to look at books more closely before buying them. > the microsoft heritage showed, too.
As somebody else asked, what exactly was wrong with _Code Complete_? grelbr
> A server is too complex and vague a task. > The vagueness comes from what functionality you want to add. > Do you support CGI and virtual servers for example? > The complexity comes from serveral fronts, mainly > the complexity of HTTP itself ( which is not that complex, but > more complex than for one junior programmer ).
Yes it is vague, but it is real life. This task has real-world programming issues stamped all over it.
It has a deadline and a specification.
Choices will have to made about the programming language implementation, trade-offs of what can be implemented in the alloted time. The programmer will have to learn about HTTP, sockets, data structures, files, parsers,...., the list goes on. Even if he only gets a very simple server done (no general URI parsers) that only serves files I would consider that a success. He will also hit the issue of testing and how to do that. Part of the conclusion is to see how well the programming language enables the programmer to be productive within the timeline.
"Wade Humeniuk" <w...@nospam.nowhere> writes: > the design and not enough "doing" the work. Its like people feel they are > actually accomplishing something, but one does not truly understand the problem > until one writes the code. In some ways getting the coding (a truly technical > specification) done will facilitate getting the design done.
I reply to this only a a foil to any who would take your statement as reason to sneer at those who talk with other programmers on their team, but it is vitally important to not go the other way here, and not communicate with one another and attempt to let the code do that work. A balance is needed. Sitting down and talking thru the problem with others is very helpful in my experience.
> Perl is certainly not a good language to learn as a beginner.
On the contrary, Perl is unique (in my experience) as a language that lets you be productive while learning only a small subset of the language. I find it terribly frustrating to have to learn (almost) an entire language before I can do anything useful in it.
> Most Perl code you will find is obfuscated, as Perl syntax promotes > obfuscation.
Perl syntax promotes expressiveness (which looks a lot like obfuscation until you're well versed in the language. ;) )
> Only a very disciplined Perl programmer would be able to > escape the self-obfuscating nature of Perl.
It's difficult not to take advantage of that /expressiveness/, once you're aware of it's power.
> Perl is the ultimate shorthand. You can express quite a bit in only a few > lines of Perl... quite powerful.. but those few lines will look like a > monkey was bashing at the keyboard unless you are a Perl expert.
Sometimes yes, sometimes no.
Perl is non-orthogonal by design. That flexibility in the syntax often allows you to write things that are both shorter *and* clearer. IMHO, the hardest code to read is where the programmer was going through contortions trying to get around the limitations of a langauge; something that's rarely necessary in Perl.
> > the design and not enough "doing" the work. Its like people feel they are > > actually accomplishing something, but one does not truly understand the problem > > until one writes the code. In some ways getting the coding (a truly technical > > specification) done will facilitate getting the design done.
> I reply to this only a a foil to any who would take your statement as > reason to sneer at those who talk with other programmers on their > team, but it is vitally important to not go the other way here, and > not communicate with one another and attempt to let the code do that > work. A balance is needed. Sitting down and talking thru the problem > with others is very helpful in my experience.
Yes I agree, much of he work getting a software team to work together is to use a common vocabulary. This vocabulary is what I think OO proponents are aiming for but the popular methodology of Spec->Design->Code->Integrate that goes along with it precribes the vocabulary too soon.
