I read the transcript of the speech (even submitted it to slashdot, got rejected), and she is a very clueful: the speech is a interesting, thoughtful and also funny read (Courtney would definitely get a +5 rating on slashdot:-), so head over there and read it.
It made me want to buy an album of hers, if only I wouldn't support the labels as well.
Actually, I received a 24bit R4k6 indy for free when they scrapped them at my CS-department. They're slow machines (with lots of coolness points, granted), so the best you can do is to ditch the machine, and use the monitor:
Put a matrox card in your PC and use the monitor with Sync-on-green under X.
Haskore is a small library for representing music written in Haskell. Haskell is a non-strict purely functional programming language. The Haskore tutorial (last update: 1997) used to contain some music notation fragments, but its author, Paul Hudak, explained to me that they were from a time that Haskell-implementations still ran inside LISP interpreters. This made it easy to snarf notation functionality from Common Music Notation (a LISP package). Now that the Haskell community moved to stand-alone compilers and interpreters, the notation functionality of Haskore is defunct.
Haskore would best be described as a `music representation formalism', and not a music notation program. If you want to produce music notation, you should consider lilypond which, incidentally, has an input grammar that closely resembles the grammar of Haskore.
[Culled from a mail to PureFiction. Hope this explains more clearly what I was trying to say originally, and not lead to flamefests]
I made a mistake by setting LilyPond code as an example, which has lots of historic baggage. And no, don't start about good design; the problem I set out to solve was much more complex than I could imagine. Trying to design stuff is relatively easy when the problem is well-known, and the requirements for the design are obvious.
In this case, neither was. You just have to try writing something, and see how it comes out. Then comes the problem with C++: going along with the general popularity of C++, you write the prototype in C++; I did. As you go along and improve the program, you abstract things into new classes, and extend it while throwing away code. However at some point you reach rock bottom with C++: you can't abstract away the fact the C++ is compiled, and you can not generate code or treat classes as objects.
It's probably been my error to start the program in C++ in the first place. That is the real design issue. And this kind of design issue is not treated anywhere in the C++ books. The language is not complete (in an abstract sense), which means that it limits you in an essential way in how you can abstract the code you write.
It is my impression that the C++ committee is also faced with limits on the language, and continually extends C++. What I can't fathom that nobody concludes
"Hey, backwards compatibility with C *and* full OOP support is too complex. Lets stop with C++ and start something new"
but they say
"great, lets bolt another thing on top of the standard."
This was the real reason behind asking my question to Bjarne. Until someone questions the design principles behind C++, it will never stop growing more complex.
Besides all this it just a pain to write tight code in the language. I tried to demonstrate this by showing a small snippet of C++. This also was a mistake, because I got an enormous amount of flak for not following other people's petty rulebooks. And lots of people here seem to think that mindlessly following rules constitutes "good programming" or "good design".
Those are the two points that I want to make. Unfortunately, my rhethorical skills are less developed than my programming skills. Maybe I should post on/. more often:-)
You managed to randomly pick one of the two most complicated files (the other being score-element.hh).
Virtual inheritance [..] You have a destructor and copy constructor, but no assignment operator. That likely means serious problems if someone tries to assign to an instance of this class.
And you know C++?
A class that has a virtual base class is part of hierarchy and usually accessed through a pointer to the baseclass. Assigning instances would lead to object slicing, which is why it has a copy-constructor and clone() function.
Some things may be prohibitvely hard to do [..] but they are still possible with C++
So what are you trying to say? That they're turing complete? Not a very useful observation.
[on the fly code generation and execution] This is one area where scheme would obviously be more efficient, but it doesnt sound like those are the types of algorithms we are talking about
Actually, the case I had in mind involved scanning all pointer members of all objects deriving from a specific class. In C++ this is very painful, because you don't have reflection. We moved all variables (including C++ pointers) into an association list, and recursively scanning that list is very easy, because you do something like
Scheme scan (Scheme s) { if (ispointer (s)) { [do_something and prehaps return UNDEFINED] } else if (ispair (s)) { Scheme a = scan (car (s)); if (a == UNDEFINED) return scan (cdr (s)); else return cons (a, scan (cdr (s))); } return s; }
(The crux is that you filter all pointers that end up as UNDEFINED, from lists in the variable association list. The C++ version had to take out the pointers of arrays in derived classes one by one which led to quadratic behavior.)
I'll admit you can do this in C++, but I don't think you can do it without duplicating a substantial part of a Scheme data structures.
Wrong! this isnt about bahavior. Its about abstraction and class data member integrity. You are confusing the two.
Of course I use encapsulation if invariants must be enforced. That is besides discussion. What I am talking about is when there is no such thing as "data member integrity".
Wrong! This is a design issue, not a language issue. Functionality shared between objects should be abstracted into a separate object
The part of the program that was the most incestuous with objects is undergoing this transformation right now, but the "objects" are going to be scheme functions, because what I want the program to do can't be expressed in C++ conveniently.
This is NOT OOP!
Maybe you should read, erm, study the following quote by Bjarne Stroustrup:
OOP wasn't a panacea. [..] [OOP] just isn't the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies.
Thanks for giving me another way to reduce code, maybe I'll add a bit of it. However, I am not sure if passing member functions that set member variables which are passed as arguments count as "elegant" in my book.
Also, sooner or later, you're going to run into speed problems in a music type-setting program. Some speed cost is inherent in the fact that your language isn't strongly typed
It's very well documented that you get more speed increase from better algorithms than from small optimizations (such as eliminating type checks).
In a more expressive language (like Python or Scheme), you have more ways to write code, so you get more chances to use better algorithms; this is in fact something that happened when we used the Scheme interpreter in LilyPond.
And your point about the cost of type checking isn't clear-cut as it seems. For genericity in C++, you need templates . Templates have a tendency lead to larger object code (well, in my experience anyway.), which in turn have lousy cache behavior.
I looked at your source archive, looks like you use public member variables in your classes, as a result you have broken encapsulation. How do you extend your classes without breaking your client code? Rewriting your client code from scratch?
The client, that's me as well. I am perfectly aware which parts of the interface are considered public which are not. I am a consenting adult (wink).
One thing that bothers me about C++ protection zealotism (encapsulation, if you will) is that it assumes that behavior is something that can be encapsulated within one class. In the program you are referring to, a large part of the behavior emerges because two objects have "shared" behavior. Putting private: everywhere constrains the code, because it forces particular code to be in a particular class. The result is that half of the code is in a class where it belongs, and the other half is not. Moving the variable to a different class merely switches the halves. (The last chapter of SICP has an interesting footnote about this as well).
In any case, my default mode is prototyping, and making everything public. The moment that a reason for encapsulation emerges, I make the relevant variables private, and the compiler catches all encapsulation violations for me. These are usually trivially to upgrade to a new interface.
I'd suggest you study TC++PL
In fact, I've read it cover to cover. I learned C++ from it.
I stand corrected. For looping over functions with one argument, you need only one template. Then you want to loop over functions with two arguments. Another template. Then you want to loop over member functions. Another template.
Catch my drift?
And this is only folding repetitive code into small loops. There is lots more that is obtuse in C++ for no good reason.
Why the hell are you constructing a new list every time you need to iterate over an existing list?
I am iterating over lists to fold repetitive code into loops. The contents might have been passed as arguments to a function, example below. I am not iterating over an existing list in the first place.
You're still missing the point:
1. C++ adds lots of overhead that is just preventable. This is the part that makes C++ generally painful
2. C++ lacks some features because it is still C with OO bolted on top. This makes C++ impossible for some projects.
real-life code sample follows (sorry for the lousy formatting). Notice that the two member variables (names ending in underscore) are not stored in lists.
for (int i=00; i != 2; i++) { if (*current[i]) { if ((*current[i])->linked_b()) { pscore_p_->add_column((*current[i])); scoreline_l_->add_column((*current[i])); } else { /* We're forgetting about this column. Dump it, and make SCM forget it.
I have learned C++, thank you. I am under the distinct impression that you have no clue. Please go here, and tell me on what you base your assertion that I don't know about C++.
it's perfectly trivial to write a single function template
And that is precisely my point: a function template takes up 5 lines of code, and using it another 2 (constructing the list, iterating). Contrast that with the one line python.
that's a sevenfold increase in code size.
Multiply the amount that you do loops over two element lists in a 50000 line program.
Now that I am reading your replies (and of course after reading your FAQ as well), I've started to notice that your replies center on the fact that C++ is better than C
Or maybe even the less subjective
Complicated programs in look better in C++ than in C
This is patently true, of course. C++ has support for various nifty features that make a large C project more easy to manage. In fact it describes precisely what I felt when I traded C++ for C: no more hassling with function pointer tables was needed. I could simply use a virtual function, great!
My problem is "better than C" is no longer good enough for me.
I've grown a lot in my programming skills, and my projects have grown with me. A little detour: my pet project is GNU LilyPond, a music typesetter (free software of course) written and maintained largely by myself: it consists of about 55000 lines of C++.
The problem with this application is that
1. music typesetting is _very_ complicated
2. every formatting detail should be tweakable.
Since I've started it almost 4 years ago, I've learned a lot, and also came in touch with languages like Python, Haskell and LISP. Half a year ago we made the step of converting large portions of the C++ side to GUILE (the embedded Scheme interpreter of the GNU project).
This step has dramatically simplified most of the code in LilyPond: now we have garbage collection, generic types without the overhead templates!, a clean way for users to plug into this system using Scheme, etc. (if you want details of what kind of uglyness went away, tell me, I can explain). This revelation caused to me reconsider C++ as the ultimate language.
In python, I can simply write
for x in func1, func2: [some complicated code with x]
in C++, I'd have to go through the hassle of defining the correct function signature as a typedef, then build an array, and then loop through that array using an integer, eg.
typedef void (*fptr)(); .. fptr[2] = {&func1,&func2} for (int i=0; i
And usually, I don't go through the hassle , and just copy and paste [something complicated], which is also a Bad Thing. Maybe this is a slightly contrived example (I'm not sure about the typedef), but learning Python and LISP has made writing C++ a generally painful experience for me.
Maybe nowadays some of my gripes may be soothed by the Standard Libraries, but I don't feel like learning yet another big C++ component, all the more because I know that afterwards C++ will still not be good enough (or will it ever have reflection, higher order functions, GC?)
In this light, I find your statement that starting to learn C++ is easier than starting to learn C
dangerous, as are the examples in your "learning C++ as a new language paper" for they imply that any of these two languages can or should be a "first" language.
Do you really want people grow up with a language that has distinction between non-immediate objects on the heap and stack, no automatic garbage collection, pointers, no initialization, no higher-order anything?
You're educating people about C++: fighting misconception, telling them where it is good for. But you're not telling them what it is bad for. C++ is immensely popular, and people easily get the misconception that this popularity makes it a good language start programming with, or to write their highly tweakable programs, etc.
[Sorry for the potential inflammatory matter in this question].
How do you relate the complexity of current C++ with the much-touted simplicity of Object Oriented Programming?
Longer explanation:
Over the years, the C++ implementation has ballooned; If I recall correctly, your book the C++PL has more than doubled in size. C++ has become a very large and complicated language, and I doubt whether there are any individuals (besides you, that is) that know the entire definition by heart, let alone teams of programmers.
This means that it is not practical to use C++ fully in any project, and one also has to set strict guidelines for a project what features to use and which not. Seen, in this light, it is doubtful whether C++ has made writing software more manageable. So I think, that as tool for writing better software more efficiently, C++ is a failure.
C++'s evolution was motivated by a few mottos (you don't pay for what you don't use, C compatibility, etc.), and seen in this light, C++ is a success. Do you think that these mottos need reconsideration?
I am not wrong on both counts
on
Copyright!
·
· Score: 1
Thanks for your try on educating me, but I am plenty aware of copyright issues already. Let me try to clarify my point.
Of course copyrights are given automatic. When I write down what my chat with the supermarket cashier this evening, indeed I have a Copyrighted Work, and I don't have to register it, granted. My supermarket conversation is protected till 70 years after I die, sure. (Assuming of course, it is lengthy enough)
The original post was referring to something different: it specifically referred to the `right' for an individual person to harvest from years of hard work on copyrighted creations.
Now tell me,
(I) how many people do you know that 1. put in years work into copyrighted matter, and 2. harvest the rewards themselves?
(II) How many people do you know are make copyrighted matter (graphics, software, etc.) as an employee of a corporation that owns their creations?
Now, compare the numbers you find in (I) and (II).
I think that maintaining the rights of the people under (I) is not very important, given their small number.
"hard work of spirited artists must be protected"
is an often cited argument for maintaining copyright. This argument simply does not reflect the economic and artistic reality of copyright exploitation today.
Re:It's all how you look at it
on
Copyright!
·
· Score: 1
This is bollocks.
99.99 % of all copyrighted and traded content is NOT owned by individuals, but by large corporations. How many individuals do you know that 1. Spend years on creating content and 2. actually own their own creations.
Your comment implicitly assumes that copyright is a natural human right. That is not so. RMS has plenty of writing that explains this.
For those who don't know, cygnus maintains most of the GNU development tools (GCC, GDB, binutils, etc.). It is a firm that has been making money off free software for ten years, mostly by porting GNU tools to embedded systems.
I think this is a sad sign: if true, with this deal, Red Hat has shown that they are not confident about their own business strategy. Now they compensate for this by buying up other (profitable) companies.
Come on guys, this is about Sibelius a music notation program. It was brought to you by the Finn brothers, the guys that programmed a RISC chip in Assembler. The article is just some free promotion for Sibelius software
Sibelius does NOT destill or mimic any musical style. If anything, it mimics the musical style of a particular programmer at Sibelius.
Mimicking and destilling style is a subject of ongoing research. You could check out the work by Douglas Cope -- who destilled stylistic features of composers. You can also head over to
http://stephanus2.socsci.kun.nl/mmm/
where there is more on music research. (I am sorry: I don't know any more links from the top of my head).
All in all, this is an interesting stuff, but Sibelius is not the place where it is happening.
Slashdot Mirror
[I posted that article on usenet]
now the interesting thing is: will they send me a cease and desist letter?
It made me want to buy an album of hers, if only I wouldn't support the labels as well.
Put a matrox card in your PC and use the monitor with Sync-on-green under X.
Haskore would best be described as a `music representation formalism', and not a music notation program. If you want to produce music notation, you should consider lilypond which, incidentally, has an input grammar that closely resembles the grammar of Haskore.
[Culled from a mail to PureFiction. Hope this explains more clearly
/. more often :-)
what I was trying to say originally, and not lead to flamefests]
I made a mistake by setting LilyPond code as an example, which has
lots of historic baggage. And no, don't start about good design; the
problem I set out to solve was much more complex than I could
imagine. Trying to design stuff is relatively easy when the problem is
well-known, and the requirements for the design are obvious.
In this case, neither was. You just have to try writing something, and
see how it comes out. Then comes the problem with C++: going along
with the general popularity of C++, you write the prototype in C++; I
did. As you go along and improve the program, you abstract things
into new classes, and extend it while throwing away code. However at
some point you reach rock bottom with C++: you can't abstract away the
fact the C++ is compiled, and you can not generate code or treat
classes as objects.
It's probably been my error to start the program in C++ in the first
place. That is the real design issue. And this kind of design issue
is not treated anywhere in the C++ books. The language is not
complete (in an abstract sense), which means that it limits you in an
essential way in how you can abstract the code you write.
It is my impression that the C++ committee is also faced with limits
on the language, and continually extends C++. What I can't fathom that
nobody concludes
"Hey, backwards compatibility with C *and* full OOP support is
too complex. Lets stop with C++ and start something new"
but they say
"great, lets bolt another thing on top of the standard."
This was the real reason behind asking my question to Bjarne. Until
someone questions the design principles behind C++, it will never
stop growing more complex.
Besides all this it just a pain to write tight code in the language. I
tried to demonstrate this by showing a small snippet of C++. This
also was a mistake, because I got an enormous amount of flak for not
following other people's petty rulebooks. And lots of people here seem
to think that mindlessly following rules constitutes "good
programming" or "good design".
Those are the two points that I want to make. Unfortunately, my
rhethorical skills are less developed than my programming skills.
Maybe I should post on
I picked a random file, translator-group.hh.
You managed to randomly pick one of the two most complicated files
(the other being score-element.hh).
Virtual inheritance [..] You have a destructor and copy
constructor, but no assignment operator. That likely means serious
problems if someone tries to assign to an instance of this class.
And you know C++?
A class that has a virtual base class is part of hierarchy and usually
accessed through a pointer to the baseclass. Assigning instances would
lead to object slicing, which is why it has a copy-constructor and
clone() function.
(So sue me, I didn't add a private operator=() )
Um, are you aware of the fact that C++ has an association list type, std::map?
I guess so, but I am pretty sure that you can't store both
Foo *
and
Array[Foo*]
(sorry, do I get larger and smaller than in HTML?)
as a value in the list, without having to fool the typechecker in complicated ways.
Some things may be prohibitvely hard to do [..] but they are
still possible with C++
So what are you trying to say? That they're turing complete? Not a
very useful observation.
[on the fly code generation and execution] This is one area where
scheme would obviously be more efficient, but it doesnt sound like
those are the types of algorithms we are talking about
Actually, the case I had in mind involved scanning all pointer members
of all objects deriving from a specific class. In C++ this is very
painful, because you don't have reflection. We moved all variables
(including C++ pointers) into an association list, and recursively
scanning that list is very easy, because you do something like
Scheme
scan (Scheme s)
{
if (ispointer (s))
{
[do_something and prehaps return
UNDEFINED]
}
else if (ispair (s))
{
Scheme a = scan (car (s));
if (a == UNDEFINED)
return scan (cdr (s));
else
return cons (a, scan (cdr (s)));
}
return s;
}
(The crux is that you filter all pointers that end up as UNDEFINED,
from lists in the variable association list. The C++ version had to
take out the pointers of arrays in derived classes one by one which
led to quadratic behavior.)
I'll admit you can do this in C++, but I don't think you can do it
without duplicating a substantial part of a Scheme data structures.
By your (flawed) logic all 3D renger engines should be written in Python or Scheme!
You are wrong. The topic that we were discussing was a music typesetter
specifically, and definitely not a 3D rendering engine.
C++ is FAR more expressive and extendible than [Scheme]
I rest my case. You have no clue.
Wrong! this isnt about bahavior. Its about abstraction and class
data member integrity. You are confusing the two.
Of course I use encapsulation if invariants must be enforced. That is
besides discussion. What I am talking about is when there is no such
thing as "data member integrity".
Wrong! This is a design issue, not a language
issue. Functionality shared between objects should be abstracted into
a separate object
The part of the program that was the most incestuous with objects is
undergoing this transformation right now, but the "objects" are going
to be scheme functions, because what I want the program to do can't be
expressed in C++ conveniently.
This is NOT OOP!
Maybe you should read, erm, study the following quote by Bjarne
Stroustrup:
OOP wasn't a panacea. [..] [OOP] just isn't the right style
for every program and for every detail of a program. Some good
abstractions are best represented outside class hierarchies.
This is a red headed stepchild of OOP!
And I happen to like redheads.
Thanks for giving me another way to reduce code, maybe I'll add a bit
of it. However, I am not sure if passing member functions that set
member variables which are passed as arguments count as "elegant" in my book.
Also, sooner or later, you're going to run into speed problems in
a music type-setting program. Some speed cost is
inherent in the fact that your language isn't strongly typed
It's very well documented that you get more speed increase from better
algorithms than from small optimizations (such as eliminating type
checks).
In a more expressive language (like Python or Scheme), you have more
ways to write code, so you get more chances to use better algorithms;
this is in fact something that happened when we used the Scheme
interpreter in LilyPond.
And your point about the cost of type checking isn't clear-cut as it
seems. For genericity in C++, you need templates . Templates have a
tendency lead to larger object code (well, in my experience anyway.),
which in turn have lousy cache behavior.
Hey,
.. you never
thanks for listening to me
(assuming you're the same guy
know with these AC comments.)
I looked at your source archive, looks like you use public member
variables in your classes, as a result you have broken
encapsulation. How do you extend your classes without breaking your
client code? Rewriting your client code from scratch?
The client, that's me as well. I am perfectly aware which parts of the
interface are considered public which are not. I am a consenting adult
(wink).
One thing that bothers me about C++ protection zealotism
(encapsulation, if you will) is that it assumes that behavior is
something that can be encapsulated within one class. In the program
you are referring to, a large part of the behavior emerges because two
objects have "shared" behavior. Putting private: everywhere
constrains the code, because it forces particular code to be in a
particular class. The result is that half of the code is in a class
where it belongs, and the other half is not. Moving the variable to a
different class merely switches the halves. (The last chapter of SICP
has an interesting footnote about this as well).
In any case, my default mode is prototyping, and making everything
public. The moment that a reason for encapsulation emerges, I make the
relevant variables private, and the compiler catches all encapsulation
violations for me. These are usually trivially to upgrade to a new
interface.
I'd suggest you study TC++PL
In fact, I've read it cover to cover. I learned C++ from it.
I stand corrected. For looping over functions with one argument, you need only one template. Then you want to loop over functions with two arguments. Another template. Then you want to loop over member functions. Another template.
/*
Catch my drift?
And this is only folding repetitive code into small loops. There is lots more that is obtuse in C++ for no good reason.
Why the hell are you constructing a new list every time you need to iterate over an existing list?
I am iterating over lists to fold repetitive code into loops. The contents might have been passed as
arguments to a function, example below. I am not iterating over an existing list in the first place.
You're still missing the point:
1. C++ adds lots of overhead that is just preventable. This is the part that makes C++ generally painful
2. C++ lacks some features because it is still
C with OO bolted on top. This makes C++ impossible for some projects.
real-life code sample follows (sorry for the lousy formatting). Notice that the two member variables (names ending in underscore) are not stored in lists.
void
Score_engraver::set_columns (Paper_column *new_command_l,
Paper_column *new_musical_l)
{
Paper_column * news[] = {new_command_l, new_musical_l};
Paper_column **current[] = {&command_column_l_, &musical_column_l_};
for (int i=00; i != 2; i++)
{
if (*current[i])
{
if ((*current[i])->linked_b())
{
pscore_p_->add_column((*current[i]));
scoreline_l_->add_column((*current[i]));
}
else
{
We're forgetting about this column. Dump it, and make SCM
forget it.
(UGH.) */
scm_unprotect_object ((*current[i])->self_scm_);
*current[i] =0;
}
}
if (news[i])
*current[i] = news[i];
}
}
it's perfectly trivial to write a single function template
And that is precisely my point: a function template takes up 5 lines of code, and using it another 2 (constructing the list, iterating). Contrast that with the one line python.
that's a sevenfold increase in code size.
Multiply the amount that you do loops over two element lists in a 50000 line program.
That's a lot of preventable complexity.
Thanks for answering my question.
..
Now that I am reading your replies (and of course after reading your
FAQ as well), I've started to notice that your replies center on the fact that
C++ is better than C
Or maybe even the less subjective
Complicated programs in look better in C++ than in C
This is patently true, of course. C++ has support for various nifty
features that make a large C project more easy to manage. In fact it
describes precisely what I felt when I traded C++ for C: no more
hassling with function pointer tables was needed. I could simply use
a virtual function, great!
My problem is "better than C" is no longer good enough for me.
I've grown a lot in my programming skills, and my projects have grown
with me. A little detour: my pet project is GNU LilyPond, a music
typesetter (free software of course) written and maintained largely by
myself: it consists of about 55000 lines of C++.
The problem with this application is that
1. music typesetting is _very_ complicated
2. every formatting detail should be tweakable.
Since I've started it almost 4 years ago, I've learned a lot, and also
came in touch with languages like Python, Haskell and LISP. Half a
year ago we made the step of converting large portions of the C++ side
to GUILE (the embedded Scheme interpreter of the GNU project).
This step has dramatically simplified most of the code in LilyPond:
now we have garbage collection, generic types without the overhead
templates!, a clean way for users to plug into this system using
Scheme, etc. (if you want details of what kind of uglyness went away,
tell me, I can explain). This revelation caused to me reconsider C++
as the ultimate language.
In python, I can simply write
for x in func1, func2:
[some complicated code with x]
in C++, I'd have to go through the hassle of defining the correct
function signature as a typedef, then build an array, and then loop
through that array using an integer, eg.
typedef void (*fptr)();
fptr[2] = {&func1,&func2}
for (int i=0; i
And usually, I don't go through the hassle , and just copy and paste
[something complicated], which is also a Bad Thing. Maybe this is a
slightly contrived example (I'm not sure about the typedef), but
learning Python and LISP has made writing C++ a generally painful
experience for me.
Maybe nowadays some of my gripes may be soothed by the Standard
Libraries, but I don't feel like learning yet another big C++
component, all the more because I know that afterwards C++ will still
not be good enough (or will it ever have reflection, higher order
functions, GC?)
In this light, I find your statement that
starting to learn C++ is easier than starting to learn C
dangerous, as are the examples in your "learning C++ as a new language
paper" for they imply that any of these two languages can or should be
a "first" language.
Do you really want people grow up with a language that has distinction
between non-immediate objects on the heap and stack, no automatic garbage
collection, pointers, no initialization, no higher-order anything?
You're educating people about C++: fighting misconception, telling
them where it is good for. But you're not telling them what it is bad
for. C++ is immensely popular, and people easily get the misconception
that this popularity makes it a good language start programming with,
or to write their highly tweakable programs, etc.
For the rest, all I can say is: do what your mommy told to you: go out a little more, have some excercise. Slashdot isn't everything.
How do you relate the complexity of current C++ with the much-touted simplicity of Object Oriented Programming?
Longer explanation:
Over the years, the C++ implementation has ballooned; If I recall correctly, your book the C++PL has more than doubled in size. C++ has become a very large and complicated language, and I doubt whether there are any individuals (besides you, that is) that know the entire definition by heart, let alone teams of programmers.
This means that it is not practical to use C++ fully in any project, and one also has to set strict guidelines for a project what features to use and which not. Seen, in this light, it is doubtful whether C++ has made writing software more manageable. So I think, that as tool for writing better software more efficiently, C++ is a failure.
C++'s evolution was motivated by a few mottos (you don't pay for what you don't use, C compatibility, etc.), and seen in this light, C++ is a success. Do you think that these mottos need reconsideration?
me too!
Thanks for your try on educating me, but I am plenty aware of copyright issues already. Let me try to clarify my point.
Of course copyrights are given automatic. When I write down what my chat with the supermarket cashier this evening, indeed I have a Copyrighted Work, and I don't have to register it, granted. My supermarket conversation is protected till 70 years after I die, sure. (Assuming of course, it is lengthy enough)
The original post was referring to something different: it specifically referred to the `right' for an individual person to harvest from years of hard work on copyrighted creations.
Now tell me,
(I) how many people do you know that 1. put in years work into copyrighted matter, and 2. harvest the rewards themselves?
(II) How many people do you know are make copyrighted matter (graphics, software, etc.) as an employee of a corporation that owns their creations?
Now, compare the numbers you find in (I) and (II).
I think that maintaining the rights of the people under (I) is not very important, given their small number.
"hard work of spirited artists must be protected"
is an often cited argument for maintaining copyright. This argument simply does not reflect the economic and artistic reality of copyright exploitation today.
This is bollocks.
99.99 % of all copyrighted and traded content
is NOT owned by individuals, but by large corporations. How many individuals do you know
that 1. Spend years on creating content and 2. actually own their own creations.
Your comment implicitly assumes that copyright
is a natural human right. That is not so. RMS has plenty of writing that explains this.
I think this is a sad sign: if true, with this deal, Red Hat has shown that they are not confident about their own business strategy. Now they compensate for this by buying up other (profitable) companies.
I don't see what the benefit is for the public.
where can I download the book?
Come on guys, this is about Sibelius a music
notation program. It was brought to you by the
Finn brothers, the guys that programmed a RISC chip in Assembler. The article is just some free promotion for Sibelius software
Sibelius does NOT destill or mimic any musical style. If anything, it mimics the musical style of a particular programmer at Sibelius.
Mimicking and destilling style is a subject of
ongoing research. You could check out the work by Douglas Cope -- who destilled stylistic features of composers. You can also head over to
http://stephanus2.socsci.kun.nl/mmm/
where there is more on music research. (I am sorry: I don't know any more links from the top of my head).
All in all, this is an interesting stuff,
but Sibelius is not the place where it is happening.