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.
> > 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.
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:
>> If you like to get advice on prgramming from a person who wrote for >> a company that has a reputation of producing shody products, and >> libraries that are poorly structured.
> Another good related book is "Rapid Development". These books are in part > about getting a defined level of quality. Depending on the circumstances, a > poor level of quality may be what the company wants.
> MSFT has a sophisticated system for monitoring the level of quality of systems > as they move through the development cycle. When the level of quality is > optimal for the company, they release. This does not mean the optimal level > for the customer though.
> Time to market and competitive issues often take precedence over quality.
One of the more humorous bits of coursework I ever did was a little course called "Software Engineering" which described in rigorous detail "How software is engineered."
No mention of marketing at all, and there was, of course, the assumption that one worked in a firm where software was actually engineered, rather than cobbled.
By all accounts, MS technical people are brilliant. It's their marketers and attorneys who are responsible for . . other things.
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.
> As someone correctly mentioned you should certainly stay from hype > languages like Java, Perl, etc. They may make you more employable in > the short term, but in the long term they will make a crappy > programmer out of your, and there's no going back: bad habbits die > hard.
Can you please explain yourself a bit here. Just because Java and Perl are popular, how will using them make you a bad programmer? Clearly, this a false statement to begin with - you can be good or bad in any language. I would just like to know how you arrived at this conclusion, because it is fasinating how you can damn an entire language for inflicting bad habits.
>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.
This is *much much much more* true of ICFP. In fact a web server does not have a specification ( otherwise it would not be vague ).
Put in simpler words if someone wanted to hire me and handed me a sheet of paper saying:
Project: Write a web server. Deadline: 30 days.
I would say "hand me a lot more pages describing what you want" before I even consider taking the jobs. Even if handed (IIRC) RCF2616 I would not take the job. ( RCF2616 is a description of a protocol, *not* a specification. )
OTOh there are many who do use the ICFP as a specification because it is a specification. Yes it's for teams of people, it's meant to be worked on full-time and it's not for someone learning a new language, but those limitations are overcome by extending the deadline to thirty days.
> Then I moved to the Vax and 68k-based Suns, where I was vaguely > aware of how the instruction set worked. Eventually I moved to > machines (PowerPC, Sparc, Alpha) where I honestly have no clue what > the architecture, let alone the assembly language, looks like. It's > just not important.
Actually I think it's important to be able to move up and down the ladder of abstraction. Implement your ideas as abstractly as possible but not more so. :-)
You should be able to take on lower-level concerns as necessary. Perhaps you find your program running more slowly than you expect. You should be able to look at a disassembly and see what it's doing in case the problem is that you've tickled some inefficiency in your compiler.
And there's nothing like a good assembly language hack....like the time I patched a terminal driver on a Honeywell DPS-6 so some guys could do print-screens on dumb terminals they were using to replace a batch of unreliable microcomputers. I walked down to talk to them and saw them using the dumb terminals. I said, `Notice any difference?' `Uh, no, not really.' I went away happy.
-- Fred Gilham gil...@csl.sri.com Behold, how good and pleasant it is when brothers dwell in unity. It is like the precious oil upon the head, running down upon the beard, upon the beard of Aaron, running down on the collar of his robes. It is like the dew of Hermon, which falls on the mountains of Zion. For there the LORD has commanded the blessing, life for evermore. -Ps 133
> Virtual machines have been "old hat" for quite some time now. It's > just another way of implementing layers of abstraction, after all. > .... > Why do I get this strange feeling that each new wave of newbies has > to reinvent the past? Oh well.
Yea, you can often recognize us old farts by the fact that we sometimes `accidently' refer to Java byte code as `P-code'.
-- Fred Gilham gil...@csl.sri.com || "If I thought there was anything at all in your arguments, I should have to be not only a theist, but an Episcopalian to boot," he said, after one interchange, reckoning that since Episcopalianism was, in his book, that than which nothing could be worse, this was an effective reductio ad absurdum. - J. R. Lucas
