A book called "Successful Lisp" is available on-line. The standard is available under the name "Common Lisp Hyperspec" (HTML). It can be used in [X]Emacs as on-line help (the elisp for it is available somewhere). The Lisp book "Common Lisp the Language, 2nd Ed" (CLTL2) by Steele is also available online. Actually the amount and quality of the material available for free surprised me when I started learning lisp.
If you're looking for a simple intro I'd suggest Graham's "ANSI Common Lisp". I also have a copy of SICP, but it's more about programming in general than lisp as a language and it's quite heavy stuff. All the recommended books on the ALU site are quite good.
UML is the UNIFIED model language. It is the unification of two publically known "object methodologies", created by Booch and Rumbaugh respectively.
You forgot Jakobson, the father of use-cases. So it's three methodologies. Personally I think the RUP and UML are a bit too hyped and commercial... there's something good, but there are also a lot of papers describing where UML is unclear and I've even seen a paper that was about formalizing the OCL (which was supposed to be formal).
MMM 0.4.1 Browser writtem in OCAML (interpreted language). Despite that fact, it's really not THAT slow.
AFAIK, The INRIA implementation of OCAML can compile and bytecode-compile OCAML, so the bit about OCAML being interpreted is incorrect. see: caml.inria.fr BTW, an OCAML entry won the ICFP contest this year.
I suspect that an evolutionary approach such as this is likely to gain more ground than forcing people to think about programming in a completely different paradigm.
You're probably right, but I can always hope otherwise.. as I don't particularly like C/C++. BTW, knowing multiple paradigms is extremely beneficial.
A sidenote on why massive parallelism isn't going to happend any time soon: There's a huge mass of software and software culture based on sequential processors and it's not likely that people will throw all that away. It's easier to build faster backwards compatible processors than to introduce new concepts and while the development tools aren't up to the modern standards the new equipment won't be accepted. What good is parallel processing if your old code in C won't run any faster on it ? Migrating to a new platform and not having anything to reuse is going to be costly.
Re:CPU speeds maxed out. Massive parallelism is ne
on
Pentium III hits 1Ghz
·
· Score: 2
I definitely hope so. For many tasks parallelism is the easier and more logical way to gain speed, for instance, neurocomputing, computer graphics, games, signal processing etc. Many of the problems could be reduced to separate problems that can be solved concurrently.
Hopefully we will also see transition from programming languages that don't support parallelism (like C/C++) to better languages that are easier to parallelize even implicitly by the compiler (like the functional and logic programming languages).
The programming tools are not really up to massive parallelism yet and it may be one factor affecting development; the change requires a paradigm shift. I don't think many people would want to program a 64 threaded program in C.
I also hope the parallelism will become fine grained where individual statements in procedures can be executed in parallel, which of course puts the burden on the compiler.
But I still don't buy that LISP is inherently faster than C++, assuming an equally comepetent compiler, which is what jd seemed to be claiming.
Of course it isn't inherently faster, just theoretically as fast. In some languages it's easier to optimize the code than in others and consequently the compilers may produce better code. In the case of C++ there has been a lot of competition and the existing implementations are quite good. I would think that most Lisp implementations produce worse code.
The thing is that IMO Lisp is more expressive than C++ and because of that better algorithms get implemented (it's easier and faster). Good algorithms affect speed more than the quality of the compiled code in many cases. If you would implement the same algorithms in C++ the result would probably be faster.
Try extracting the nth element from a list in C++ in less than O(n) using the standard linked list data structure. You could make a fortune with that algorithm;) In my experience most Lisps in serious use are at least bytecode-compiled and most are compiled to native code.
A list is not the only data structure available in Lisp. For instance, Common Lisp has arrays just like C/C++ and they're as fast with proper type-declarations. Lisp is not inherently slower than C/C++; you just have to work a bit more to make it as fast. A Lisp program could be faster than C because it's easier to implement better algorithms in Lisp or because the Lisp compiler is better than the C compiler. The important thing in optimizing Lisp is to declare types and to avoid dynamic memory allocation during speed-critical code.
I've seen some numerical code go faster in CMUCL (a high quality free Common Lisp compiler for Linux/*BSD) than the equivalent in g++ (with all relevant optimizations, 10% difference in speed in favor of CMUCL), just because the CMUCL compiler is excellent in number crunching.
But it also includes facilities to combine many different forms of music for instance (ever heard of MPEG-4 SAOL, structured audio orchestra language). SAOL includes the instrumental data. You can combine synthesis (as specified in the standard, i think) with audio streams. For example, tracker-style music with sampled lyrics. That's pretty much compression, if you produce the music with MPEG-4. If I understood it correcly (the subject jumps up occasionally at music-dsp) MPEG-4 is quite different from the previous MPEGs.
...those academic physical models keep getting better. There's some research being done at least at the CCRMA at Stanford and the acoustics lab at the Helsinki University of Technology and probably other places too.
Sampling technology can't imitate all instruments well enough. This is where physical modeling comes in. Consider the guitar... every string can crossmodulate the other strings as you play it causing subtle differences in the sound. You can slide a note and it won't sound realistic if you just play the sample faster; the effect is different. Realistically to get a good guitar sound on a sampler you would need too many samples and extremely complicated logic to select the sample being played.
IMO traditional computer music instruments are getting a bit boring and unexpressive (TB-303, TR-{808,909} anyone ?). I'd really like to see (and hear) something more subtly expressive catch on.
Oh, really. Since software patents aren't allowed here I could take any idea and steal it and the companies couldn't do anything. The US market is not the only one and still companies do research. Why do you automatically assume that IP is needed for companies to do research ? It may feel obvious but it isn't. No patents or shorter duration patents would mean that the competition would focus on implementation. This is not a bad thing. Now, the speed IT is moving, the ideas in patents are obsolete before the patent expires and while the patent is valid the companies get away with a bad implementation.
If we must have software patents, then at least limit their scope to 3-5 years instead of what they have now. IMO patents are slowing down progress. Currently patents are the companies' way to do battle. They're too expensive for individuals and smaller companies so they are actually slowing down small innovative companies. I've done some compression research and almost every method I've run into has been patented, so anything I build on top of those would actually be unusable in the US. Why do you think mp3 uses Huffman instead of the more efficient arithmetic coding ? Simple, arithmetic coding is patented. So we ended up with a suboptimal standard, because of patents. nice.
Algorithm patents are ridiculous, you might as well patent mathematics. Clearly algorithms are mathematics and therefore should be unpatentable. Otherwise we would end up with patents like "a method for computing the area of a square". Where do you draw the line of obvious ? Given the ignorance IP lawyers in companies, they will probably try to patent algorithms that have been known for a long time and given the ignorance of the USPTO they will get the patent. Then they will go to court and waste a lot of time and money and the lawyers will get rich.
Software patents will kill innovative free software. A free software author can not defend himself in court against a company and he has no resources to check if he has used something that is patented. Given any idea scientific article, it's quite possible that if you refine the idea, it has already been done and patented, or the original idea has a patent that covers your refinement. A free software author will hear the voices of companies saying: "Do ya feel lucky, punk ?", every time he releases new software. Maybe they should make non-profit software an exception ? It's only fair that the inventor gets his share of the _profits_, which are $0 for free software. BTW, I equate the right to release source with free speech.
I'm a scientist as well. I don't have a problem with not being able to patent my findings. I get my kicks from finding and learning new things and hopefully someday seeing them flourish.
Well, with C++ you're not wasting your time. Many companies want employees that know C++ and C++ is not going away any time soon, so it would be irresponsible for me to say that don't learn C++. C++ is probably one of the most used languages today, the other two are Java and VB. Perl is also widely used.
My definition of "better" is subjective; for some tasks C++ is very good, and for some tasks it sucks. If you need the maximum efficiency combined with portability (e.g. games) then C++ is hard to beat. If you want to write programs that are easily extended (i.e. have plugins or some other way to add functionality, e.g. emacs) then C++ isn't that good, there's a lot of red tape involved. Also writing safe code in C++ is harder than in many languages, which is the main reason to use other languages. Starting C++ you will have to spend a significant amount of time debugging, since C++ doesn't check for array bounds, memory leaks, invalid pointers etc. and it's very easy to miss an error when debugging. However, there is software that can help you debug.
There's an existing efficiency fetish that efficiency makes up for everything else. When someone says that language Y is safer, has GC, etc. then the language X zealot dismisses all this with: "but X is more efficient", even if the difference isn't noticeable. I personally disagree with this view. In many cases producing reliable functional software quickly is more important than attaining maximum efficiency.
For the better languages: Smalltalk, Dylan and Common Lisp for instance (at least Dylan and CL have free compilers for Linux). All of them can be compiled to native code and are quite efficient when the programmer knows what he is doing. Dylan has a more conventional syntax than the two others. I've also heard good things about python. I guess this depends on the application area you're interested in... I personally like Common Lisp; it seems to be a mature well thought out language, but it may not be everyone's cup of tea. Like I said it depends on the application area, you can always find an area where these don't work as well as some other language, but there's no such thing as a perfect language (CL comes close though;)).
A few days to learn another one ? Maybe if we're talking about pascal-c-fortran and related languages, where the differences are mostly syntactical. C++ is a complex multiparadigm language. Yes, you may learn the syntax and continue your present practices in the language, but have you learnt the spirit of the language ? I would say that you have not.
Here's a challege: Learn to write good Common Lisp or Prolog in a few days.
You don't develop those in a hurry. It took me a few years, but now I know the language inside and out and don't need the reference-books. Of course, now I'm moving to better languages (the dynamic ones)... I wish I had moved to them earlier, since C++ has a lot of problems in dynamic applications. I still have to use C++ for work though.
Strong C++ skills also include strong programming skills and those take a few years as well. The only thing that can make a good programmer is _experience_. Now looking back a few years, when I thought that I was a good programmer, the code looks like crap, a few years from now the code I write now will look like crap. There's always room for improvement.
I think the point where you really are good with language is when you've written something bigger with it (including design, my bigger project was around 20 KLOC). When the total lines of code you've written in that language is around 100000 then you should pretty much know it. I've written way more than that in C++. My point is that you can't become a good C++ programmer in 21 days, or even 21 weeks. Maybe you learn enough to work for a company in desperate need for new programmers, but not well enough to write well-designed C++.
It's not a bad start, but don't expect to get good without a lot of practice. If you already know how to program, then you may learn C++ a lot faster. I made the mistake of learning C++ as the first serious language and it probably slowed my learning down a lot. Had I learned a simpler language well-enough first, I would probably have learned C++ faster. The size of the language and the amount of idioms (small coding tricks, the C++ way of doing things) in C++ is overwhelming.
To seriously learn C++ I suggest that you learn OOA/D (good code requires good analysis of the problem and good design !) from, for instance, Rumbaugh's or Jakobson's books (I don't like Booch). For the small C++ tricks there's Coplien's book on C++ idioms (can't remember the exact name). The book "Design Patterns: Elements of reusable object-oriented software" is one of the classics of OOP. Scott Myers' "Effectice C++" and "More Effective C++" may be of some use to more advanced C++ programmers. You learn most of these things with enough practice, but why learn through trial-and-error (like I did), when the books can give you a head start and spare you of the worst.
Oh and wasn't Edgar Dijkstra also associated with "GOTO considered harmful" - which just goes to show that he either a) never wrote on-the-metal error handler in his life - setjmp() and longjmp() anyone? or b) was a hypocrite (and yes, I have read GCH - and GCHCH...)
It's Edsger, not Edgar. GCH is IMO one of the most influential articles, which brought programming out of the dark ages. You can't deduce anything about the program's state by the position of execution if the program is littered with undisciplined GOTOs. Dijkstra is a theoretician, who wants to create bugless software and he isn't a hypocrite. I've also read "A discipline of programming", where he develops the SVC and WP transformers and the axiomatic method of proving program correctness, and his book in monographs in CS. One of his more famous statements is that "Testing can only show the presence of bugs, not their absence."
There are structured ways to do error handling. Setjmp and longjmp are just one way to handle errors, C has no other; there are other ways... but maybe not in UNIX.
A model in which an Ellipse may or may not be a Circle from moment to moment, or in which some instances add secret invariants, is only appropriate for a language with classes but no types, where clients have to be ready for anything because they have no guarantees about how an object will behave.
No they don't, since the behaviour of the methods is specified in the post-conditions. The problem is that the superclass may have methods (for convenience or efficiency perhaps) that are impossible to implement in a class that would be the logical subclass while maintaining it's invariant. In this case it is most likely that there is a superclass missing in the design that could provide the necessary substitutability of classes. Mutability in the superclass usually leads to problems. Secret invariants ? What are you talking about ? The invariant of the subclass is the union of all the invariants of it's superclasses and the new conditions it adds. It is stricter than that of the superclass and it's the duty of the subclasses methods to enforce it.
This also a question whether the traditional OO approach can model the world as such to an acceptable degree or not. OO breaks in the circle vs. ellipse case. The relation between the usual Circle and Ellipse is IS-A in the mathematical sense. Sometimes the world has to be bent around the OO conceptual primitives. In dynamic languages the OO primitives can sometimes be extended to cover these situations. For instance the the transformation from Circle to Ellipse can be implemented in a static language with a design pattern called Bridge, which is quite contorted to plain metamorphism. Metamorphism is perfectly valid in some models, for instance, consider the lifecycle of a butterfly.
Liskov-substitutability is already violated when there are the classes of circle and ellipse in the design and ellipse has methods that can't be implemented for a circle while maintaining it's invariant. I know this is a bit backwards, since the design of the superclass has to take into account the subclasses.
It depends on whether you view subclassing as extension or superclassing as generalisation. In my point of view subclasses can also add new constraints so actually the methods of the would-be superclass may violate the invariants of the subclasses (this is a bitch for maintenance if the superclass isn't abstract enough). So the methods that would cause that violation would have to be removed and the superclass made more abstract by moving the methods down to those classes where they don't threaten to violate the invariants. In some cases you could just change the class of the object in question when such a method is used. The question is about mutability, the base classes that account for substitutability shouldn't be too mutable or you can run into problems, rather they should be abstract and take into account the future limitations that subclasses may require.
In the mathematical world the circle is a subclass of the ellipse. It is an ellipse with certain constraints, which allow some optimizations to take place in the implementation. Yes a circle is substitutable for an ellipse provided that the ellipse class has no methods that would violate the circle's invariant or the circle object would then change into an ellipse object, which is what it logically does, when you for example scale it in the X direction only. In this case there's the problem of someone else expecting it to remain a circle...
Ok, I'm not saying that you can't do things without MI, but if your logical analysis of the problem domain ends up with a model that has MI then you _shouldn't_ change the model not to use MI. This means giving up the seamlessness of OO from analysis to implementation.
This may sound like methodologist ranting, but the cleaner the mapping from the analysis model to the implementation model the better. I wonder what is the real world conceptual counterpart of an inner class or interface. Well, clearly I'm biased toward the methodological and philosophical side of OO, while most people in the US are being taught the pragmatic side of OO (dependency management and modularity). The philosophical side of OO, clean mapping from analysis model to implementation, is easier to implement in dynamic languages. CLOS for instance can do an extremely clean implementation of the multiple dispatch and the circle vs. ellipse dilemma can be solved using the polymorphic abilities of the language.
Circle is a subclass of ellipse, no question about it. The problem is that the superclass probably has operations that may violate the invariant of the subclass, which is a bit backwards... This is a problem of the static languages, they attach the form (struct) of the implementation tightly to the logical object, which leads to problems in certain situations like the circle-ellipse case. The solutions to these kinds of problems are usually quite contorted.
> Did you read this at all? This isn't a software patent!
From the linked article: "covers any type of digital audio player used to store and play back downloaded content,"
Which, judging by the article, covers PC's and the software to play them back. I dug a little deeper and found it applies to portable players, which have software components as well. This not what the linked article lets you to believe... (it says quite clearly "any type of...")
Nevertheless, it is in the same spirit as the software patents. It's a patent on an idea, not an implementation. It's just the same to me. The patent is saying that you can't think in this way. Come to think of it, I'm against all patents that grant the owners a monopoly on their ideas for too long (2-3 years is enough)
IMO, You could use some basic training in manners...
Don't bloody give into this one or any other software patent. They can't sue everybody, break it together and boycott all products from that firm.
The US patent system is stupid. I hope we don't get the same system in Europe... M$ is lobbying for it for sure.
Try to infringe on all patents you can and then see them trying to sue every last one of you. All software patents should be banned. It's like you can't think the way you want, you can't produce the things you're capable of or you risk being sued. This is true even for free software.
The only way to beat it is passive resistance, infringe everything... What are they going to do ? Lock every programmer up... I seriously doubt it. Maybe we should create "Softpeace", which would promote software freedom the way Greenpeace does nature, only the targets would be the companies with patents.
Of course copyrights are a different story, violating them is stealing, which I would never advocate.
Programmers unite against the biggest threat to your freedom !
> Or, like Microsoft, invent all sorts of diffrent > descriptions of invented and imaginary things > and make them as fuzzy as possible, patent them > and hope that someday, someone will invent > something that could be covered by their patents > so they can sue for patent infringments.
And wait till it gets popular before they sue, so they get money without working for it.
In one instance I started to write a modular software synthesizer that produces compiled code from signal processing network descriptions (still working on it). I found a M$ patent on componentized signal processing, which is about the same thing (ie. generate code run-time from abstract filter descriptions to cut procedure call overhead, reverb was mentioned). The M$ patent was filed in June 1997 and Common Lisp Music, which is from 1991 has done it already, we discussed this on music-dsp and other companies had also done this but not patented it. So much for knowledge of events outside the company boundary. I'm not even aware if they are using this thing anywhere. If this was a valid patent (which it isn't, because of prior art, the important stuff isn't valid anyway) you could say byebye to efficient modular software synthesizers that emulate old analog software synthesizers (that is, from anyone else than M$).
Slashdot Mirror
Take a look at: Association of Lisp Users.
A book called "Successful Lisp" is available on-line. The standard is available under the name "Common Lisp Hyperspec" (HTML). It can be used in [X]Emacs as on-line help (the elisp for it is available somewhere). The Lisp book "Common Lisp the Language, 2nd Ed" (CLTL2) by Steele is also available online. Actually the amount and quality of the material available for free surprised me when I started learning lisp.
If you're looking for a simple intro I'd suggest Graham's "ANSI Common Lisp". I also have a copy of SICP, but it's more about programming in general than lisp as a language and it's quite heavy stuff. All the recommended books on the ALU site are quite good.
You forgot Jakobson, the father of use-cases. So it's three methodologies. Personally I think the RUP and UML are a bit too hyped and commercial... there's something good, but there are also a lot of papers describing where UML is unclear and I've even seen a paper that was about formalizing the OCL (which was supposed to be formal).
AFAIK, The INRIA implementation of OCAML can compile and bytecode-compile OCAML, so the bit about OCAML being interpreted is incorrect. see: caml.inria.fr BTW, an OCAML entry won the ICFP contest this year.
You're probably right, but I can always hope otherwise.. as I don't particularly like C/C++. BTW, knowing multiple paradigms is extremely beneficial.
A sidenote on why massive parallelism isn't going to happend any time soon: There's a huge mass of software and software culture based on sequential processors and it's not likely that people will throw all that away. It's easier to build faster backwards compatible processors than to introduce new concepts and while the development tools aren't up to the modern standards the new equipment won't be accepted. What good is parallel processing if your old code in C won't run any faster on it ? Migrating to a new platform and not having anything to reuse is going to be costly.
I definitely hope so. For many tasks parallelism is the easier and more logical way to gain speed, for instance, neurocomputing, computer graphics, games, signal processing etc. Many of the problems could be reduced to separate problems that can be solved concurrently.
Hopefully we will also see transition from programming languages that don't support parallelism (like C/C++) to better languages that are easier to parallelize even implicitly by the compiler (like the functional and logic programming languages).
The programming tools are not really up to massive parallelism yet and it may be one factor affecting development; the change requires a paradigm shift. I don't think many people would want to program a 64 threaded program in C.
I also hope the parallelism will become fine grained where individual statements in procedures can be executed in parallel, which of course puts the burden on the compiler.
Of course it isn't inherently faster, just theoretically as fast. In some languages it's easier to optimize the code than in others and consequently the compilers may produce better code. In the case of C++ there has been a lot of competition and the existing implementations are quite good. I would think that most Lisp implementations produce worse code.
The thing is that IMO Lisp is more expressive than C++ and because of that better algorithms get implemented (it's easier and faster). Good algorithms affect speed more than the quality of the compiled code in many cases. If you would implement the same algorithms in C++ the result would probably be faster.
Try extracting the nth element from a list in C++ in less than O(n) using the standard linked list data structure. You could make a fortune with that algorithm ;) In my experience most Lisps in serious use are at least bytecode-compiled and most are compiled to native code.
A list is not the only data structure available in Lisp. For instance, Common Lisp has arrays just like C/C++ and they're as fast with proper type-declarations. Lisp is not inherently slower than C/C++; you just have to work a bit more to make it as fast. A Lisp program could be faster than C because it's easier to implement better algorithms in Lisp or because the Lisp compiler is better than the C compiler. The important thing in optimizing Lisp is to declare types and to avoid dynamic memory allocation during speed-critical code.
I've seen some numerical code go faster in CMUCL (a high quality free Common Lisp compiler for Linux/*BSD) than the equivalent in g++ (with all relevant optimizations, 10% difference in speed in favor of CMUCL), just because the CMUCL compiler is excellent in number crunching.
For more information see Association of Lisp Users, CMUCL is available at www.cons.org.
But it also includes facilities to combine many different forms of music for instance (ever heard of MPEG-4 SAOL, structured audio orchestra language). SAOL includes the instrumental data. You can combine synthesis (as specified in the standard, i think) with audio streams. For example, tracker-style music with sampled lyrics. That's pretty much compression, if you produce the music with MPEG-4. If I understood it correcly (the subject jumps up occasionally at music-dsp) MPEG-4 is quite different from the previous MPEGs.
MPEG-4
Sampling technology can't imitate all instruments well enough. This is where physical modeling comes in. Consider the guitar... every string can crossmodulate the other strings as you play it causing subtle differences in the sound. You can slide a note and it won't sound realistic if you just play the sample faster; the effect is different. Realistically to get a good guitar sound on a sampler you would need too many samples and extremely complicated logic to select the sample being played.
IMO traditional computer music instruments are getting a bit boring and unexpressive (TB-303, TR-{808,909} anyone ?). I'd really like to see (and hear) something more subtly expressive catch on.
Oh, really. Since software patents aren't allowed here I could take any idea and steal it and the companies couldn't do anything. The US market is not the only one and still companies do research. Why do you automatically assume that IP is needed for companies to do research ? It may feel obvious but it isn't. No patents or shorter duration patents would mean that the competition would focus on implementation. This is not a bad thing. Now, the speed IT is moving, the ideas in patents are obsolete before the patent expires and while the patent is valid the companies get away with a bad implementation.
If we must have software patents, then at least limit their scope to 3-5 years instead of what they have now. IMO patents are slowing down progress. Currently patents are the companies' way to do battle. They're too expensive for individuals and smaller companies so they are actually slowing down small innovative companies. I've done some compression research and almost every method I've run into has been patented, so anything I build on top of those would actually be unusable in the US. Why do you think mp3 uses Huffman instead of the more efficient arithmetic coding ? Simple, arithmetic coding is patented. So we ended up with a suboptimal standard, because of patents. nice.
Algorithm patents are ridiculous, you might as well patent mathematics. Clearly algorithms are mathematics and therefore should be unpatentable. Otherwise we would end up with patents like "a method for computing the area of a square". Where do you draw the line of obvious ? Given the ignorance IP lawyers in companies, they will probably try to patent algorithms that have been known for a long time and given the ignorance of the USPTO they will get the patent. Then they will go to court and waste a lot of time and money and the lawyers will get rich.
Software patents will kill innovative free software. A free software author can not defend himself in court against a company and he has no resources to check if he has used something that is patented. Given any idea scientific article, it's quite possible that if you refine the idea, it has already been done and patented, or the original idea has a patent that covers your refinement. A free software author will hear the voices of companies saying: "Do ya feel lucky, punk ?", every time he releases new software. Maybe they should make non-profit software an exception ? It's only fair that the inventor gets his share of the _profits_, which are $0 for free software. BTW, I equate the right to release source with free speech.
I'm a scientist as well. I don't have a problem with not being able to patent my findings. I get my kicks from finding and learning new things and hopefully someday seeing them flourish.
Well, with C++ you're not wasting your time. Many companies want employees that know C++ and C++ is not going away any time soon, so it would be irresponsible for me to say that don't learn C++. C++ is probably one of the most used languages today, the other two are Java and VB. Perl is also widely used.
My definition of "better" is subjective; for some tasks C++ is very good, and for some tasks it sucks. If you need the maximum efficiency combined with portability (e.g. games) then C++ is hard to beat. If you want to write programs that are easily extended (i.e. have plugins or some other way to add functionality, e.g. emacs) then C++ isn't that good, there's a lot of red tape involved. Also writing safe code in C++ is harder than in many languages, which is the main reason to use other languages. Starting C++ you will have to spend a significant amount of time debugging, since C++ doesn't check for array bounds, memory leaks, invalid pointers etc. and it's very easy to miss an error when debugging. However, there is software that can help you debug.
There's an existing efficiency fetish that efficiency makes up for everything else. When someone says that language Y is safer, has GC, etc. then the language X zealot dismisses all this with: "but X is more efficient", even if the difference isn't noticeable. I personally disagree with this view. In many cases producing reliable functional software quickly is more important than attaining maximum efficiency.
For the better languages: Smalltalk, Dylan and Common Lisp for instance (at least Dylan and CL have free compilers for Linux). All of them can be compiled to native code and are quite efficient when the programmer knows what he is doing. Dylan has a more conventional syntax than the two others. I've also heard good things about python. I guess this depends on the application area you're interested in... I personally like Common Lisp; it seems to be a mature well thought out language, but it may not be everyone's cup of tea. Like I said it depends on the application area, you can always find an area where these don't work as well as some other language, but there's no such thing as a perfect language (CL comes close though ;)).
A few days to learn another one ? Maybe if we're talking about pascal-c-fortran and related languages, where the differences are mostly syntactical. C++ is a complex multiparadigm language. Yes, you may learn the syntax and continue your present practices in the language, but have you learnt the spirit of the language ? I would say that you have not.
Here's a challege: Learn to write good Common Lisp or Prolog in a few days.
You don't develop those in a hurry. It took me a few years, but now I know the language inside and out and don't need the reference-books. Of course, now I'm moving to better languages (the dynamic ones)... I wish I had moved to them earlier, since C++ has a lot of problems in dynamic applications. I still have to use C++ for work though.
Strong C++ skills also include strong programming skills and those take a few years as well. The only thing that can make a good programmer is _experience_. Now looking back a few years, when I thought that I was a good programmer, the code looks like crap, a few years from now the code I write now will look like crap. There's always room for improvement.
I think the point where you really are good with language is when you've written something bigger with it (including design, my bigger project was around 20 KLOC). When the total lines of code you've written in that language is around 100000 then you should pretty much know it. I've written way more than that in C++. My point is that you can't become a good C++ programmer in 21 days, or even 21 weeks. Maybe you learn enough to work for a company in desperate need for new programmers, but not well enough to write well-designed C++.
It's not a bad start, but don't expect to get good without a lot of practice. If you already know how to program, then you may learn C++ a lot faster. I made the mistake of learning C++ as the first serious language and it probably slowed my learning down a lot. Had I learned a simpler language well-enough first, I would probably have learned C++ faster. The size of the language and the amount of idioms (small coding tricks, the C++ way of doing things) in C++ is overwhelming.
To seriously learn C++ I suggest that you learn OOA/D (good code requires good analysis of the problem and good design !) from, for instance, Rumbaugh's or Jakobson's books (I don't like Booch). For the small C++ tricks there's Coplien's book on C++ idioms (can't remember the exact name). The book "Design Patterns: Elements of reusable object-oriented software" is one of the classics of OOP. Scott Myers' "Effectice C++" and "More Effective C++" may be of some use to more advanced C++ programmers. You learn most of these things with enough practice, but why learn through trial-and-error (like I did), when the books can give you a head start and spare you of the worst.
Oh and wasn't Edgar Dijkstra also associated with "GOTO considered harmful" - which just goes to show that he either a) never wrote on-the-metal error handler in his life - setjmp() and longjmp() anyone? or b) was a hypocrite (and yes, I have read GCH - and GCHCH...)
It's Edsger, not Edgar. GCH is IMO one of the most influential articles, which brought programming out of the dark ages. You can't deduce anything about the program's state by the position of execution if the program is littered with undisciplined GOTOs. Dijkstra is a theoretician, who wants to create bugless software and he isn't a hypocrite. I've also read "A discipline of programming", where he develops the SVC and WP transformers and the axiomatic method of proving program correctness, and his book in monographs in CS. One of his more famous statements is that "Testing can only show the presence of bugs, not their absence."
There are structured ways to do error handling. Setjmp and longjmp are just one way to handle errors, C has no other; there are other ways... but maybe not in UNIX.
No they don't, since the behaviour of the methods is specified in the post-conditions. The problem is that the superclass may have methods (for convenience or efficiency perhaps) that are impossible to implement in a class that would be the logical subclass while maintaining it's invariant. In this case it is most likely that there is a superclass missing in the design that could provide the necessary substitutability of classes. Mutability in the superclass usually leads to problems. Secret invariants ? What are you talking about ? The invariant of the subclass is the union of all the invariants of it's superclasses and the new conditions it adds. It is stricter than that of the superclass and it's the duty of the subclasses methods to enforce it.
This also a question whether the traditional OO approach can model the world as such to an acceptable degree or not. OO breaks in the circle vs. ellipse case. The relation between the usual Circle and Ellipse is IS-A in the mathematical sense. Sometimes the world has to be bent around the OO conceptual primitives. In dynamic languages the OO primitives can sometimes be extended to cover these situations. For instance the the transformation from Circle to Ellipse can be implemented in a static language with a design pattern called Bridge, which is quite contorted to plain metamorphism. Metamorphism is perfectly valid in some models, for instance, consider the lifecycle of a butterfly.
Liskov-substitutability is already violated when there are the classes of circle and ellipse in the design and ellipse has methods that can't be implemented for a circle while maintaining it's invariant. I know this is a bit backwards, since the design of the superclass has to take into account the subclasses.
It depends on whether you view subclassing as extension or superclassing as generalisation. In my point of view subclasses can also add new constraints so actually the methods of the would-be superclass may violate the invariants of the subclasses (this is a bitch for maintenance if the superclass isn't abstract enough). So the methods that would cause that violation would have to be removed and the superclass made more abstract by moving the methods down to those classes where they don't threaten to violate the invariants. In some cases you could just change the class of the object in question when such a method is used. The question is about mutability, the base classes that account for substitutability shouldn't be too mutable or you can run into problems, rather they should be abstract and take into account the future limitations that subclasses may require.
In the mathematical world the circle is a subclass of the ellipse. It is an ellipse with certain constraints, which allow some optimizations to take place in the implementation. Yes a circle is substitutable for an ellipse provided that the ellipse class has no methods that would violate the circle's invariant or the circle object would then change into an ellipse object, which is what it logically does, when you for example scale it in the X direction only. In this case there's the problem of someone else expecting it to remain a circle...
Ok, I'm not saying that you can't do things without MI, but if your logical analysis of the problem domain ends up with a model that has MI then you _shouldn't_ change the model not to use MI. This means giving up the seamlessness of OO from analysis to implementation.
This may sound like methodologist ranting, but the cleaner the mapping from the analysis model to the implementation model the better. I wonder what is the real world conceptual counterpart of an inner class or interface. Well, clearly I'm biased toward the methodological and philosophical side of OO, while most people in the US are being taught the pragmatic side of OO (dependency management and modularity). The philosophical side of OO, clean mapping from analysis model to implementation, is easier to implement in dynamic languages. CLOS for instance can do an extremely clean implementation of the multiple dispatch and the circle vs. ellipse dilemma can be solved using the polymorphic abilities of the language.
Circle is a subclass of ellipse, no question about it. The problem is that the superclass probably has operations that may violate the invariant of the subclass, which is a bit backwards... This is a problem of the static languages, they attach the form (struct) of the implementation tightly to the logical object, which leads to problems in certain situations like the circle-ellipse case. The solutions to these kinds of problems are usually quite contorted.
> Did you read this at all? This isn't a software patent!
...")
From the linked article:
"covers any type of digital audio player used to store and play back downloaded content,"
Which, judging by the article, covers PC's and the software to play them back. I dug a little deeper and found it applies to portable players, which have software components as well. This not what the linked article lets you to believe... (it says quite clearly "any type of
Nevertheless, it is in the same spirit as the software patents. It's a patent on an idea, not an implementation. It's just the same to me. The patent is saying that you can't think in this way. Come to think of it, I'm against all patents that grant the owners a monopoly on their ideas for too long (2-3 years is enough)
IMO, You could use some basic training in manners...
Don't bloody give into this one or any other software patent. They can't sue everybody, break it together and boycott all products from that firm.
The US patent system is stupid. I hope we don't get the same system in Europe... M$ is lobbying for it for sure.
Try to infringe on all patents you can and then see them trying to sue every last one of you. All software patents should be banned. It's like you can't think the way you want, you can't produce the things you're capable of or you risk being sued. This is true even for free software.
The only way to beat it is passive resistance, infringe everything... What are they going to do ? Lock every programmer up... I seriously doubt it. Maybe we should create "Softpeace", which would promote software freedom the way Greenpeace does nature, only the targets would be the companies with patents.
Of course copyrights are a different story, violating them is stealing, which I would never advocate.
Programmers unite against the biggest threat to your freedom !
> Or, like Microsoft, invent all sorts of diffrent
> descriptions of invented and imaginary things
> and make them as fuzzy as possible, patent them
> and hope that someday, someone will invent
> something that could be covered by their patents
> so they can sue for patent infringments.
And wait till it gets popular before they sue, so they get money without working for it.
In one instance I started to write a modular software synthesizer that produces compiled code from signal processing network descriptions (still working on it). I found a M$ patent on componentized signal processing, which is about the same thing (ie. generate code run-time from abstract filter descriptions to cut procedure call overhead, reverb was mentioned). The M$ patent was filed in June 1997 and Common Lisp Music, which is from 1991 has done it already, we discussed this on music-dsp and other companies had also done this but not patented it. So much for knowledge of events outside the company boundary. I'm not even aware if they are using this thing anywhere. If this was a valid patent (which it isn't, because of prior art, the important stuff isn't valid anyway) you could say byebye to efficient modular software synthesizers that emulate old analog software synthesizers (that is, from anyone else than M$).
Things like this shouldn't be said anonymously. It was me and I stand by it (just created an account to say this).