also, most artists have no experience marketing, selling, or dealing with the right people that will get them the high-paying gigs they need to continue performing and feed their family and or make the rent.
Yep, presumably artists will still need outside help to help them finance, organise and arrange large live gigs. However, I think there's less of a need for recording companies to market and distribute music from artists. Distributing music via the Internet is obviously cheap enough not to need financial backing; I need hardly go into the details of that on Slashdot. But marketing music is also a industry I expect to decline in the next few years. Music is an odd thing, in that one cannot 'sell' a piece of music in the same way one would sell a car. The customer either likes the piece of music he hears, or he does not. No amount of salesmanship will get him to change his mind, as it boils down to personal preference.
Because of this, marketing music consists largely of getting people to listen to it. Unfortunately, people have limited time on their hands, and cannot listen to every piece of music, so recording companies market selectively, using bands they know have a wide appeal. It's a broad, scattergun approach, and I can't help but think that one could do a far better job with a large database and some social networking software.
But how many generations had their kids sitting in front of, essentially, puppet-shows (or some other analog equivalent) all day, every day?
I'd say that was last generation. Puppet shows are passive entertainment, and the nearest modern equivalent to that is television. A not insignificant proportion of time that would have in the past been spent watching TV, is now spent on playing video games. Whether interactive electronic entertainment is better than passive is debatable, but is there any evidence that it's any worse?
Give it time. And then the "next big thing" will come along, and the Internet will be no more interesting than a ham radio today.
I disagree. The Internet is a worldwide network of computers; it's unlikely that we'll stop needing to use computers, or stop needing to network them any time soon. It is probable that eventually the protocols and methods of transporting information will change, but the Internet itself is too broad a concept to come to an end due to technological progress in the near future.
There's never any proof per se in science. There have been, however, many experiments, observations and measurements of cosmic rays since they were discovered in 1912. In 1954, MITT used 11 scintillation detectors to measure the energy spectrum of cosmic rays, and found it to extend beyond 1e20 eV. To put that into perspective, our largest particle accelerator, the Tetravon Accelerator at CERN, can only manage 1e12 eV. We'd need over 100 million times the power to start getting beyond the capability of cosmic rays, which is a pretty comfortable margin in my book:)
I've only seen Cars, Nemo, and Toy Story (1 and 2). So you're right in that sense.
You've already said that Toy Story is the exception to your generalisation about Pixar movies, but I can't see how you consider Nemo to fit. There is no "hero (who is known to be great)", and there is no particular event that "forces him to reprove that greatness", nor does any protagonist in the film meet and marry the "only cute single female in the movie".
Nor does the Incredibles fit your generalisation by any stretch of the imagination, and Monsters Inc. doesn't tie in well, either. Indeed, the only movie that seems to fit is Cars; no other movie Pixar movie comes close.
I recommend you watch the Incredibles, by the way; it's easily one of the best movies Pixar have produced.
Primary cosmic rays impact the earth all the time, and these often have far higher energies than even our largest particle accelerators are capable of producing. For any experiment we attempt, we can be reasonably sure that colliding cosmic rays have already produced the same results, sometime within the past few billions years. If we could create massively destructive black holes through our particle accelerators, one would expect that stray cosmic rays would have already done so.
It's not required to route Tor traffic from other users in order to make use of Tor. In order to serve as a Tor router, you need to download, setup and configure a separate Tor server package. The Tor client package just makes use of the Tor servers already available.
Sure, large clusters of powerful servers working in tandem(or quantum computing) may render the factoral math behind crypto obsolete.
Raw power alone cannot overcome modern encryption. One either has to find a flaw in the encryption algorithm, or the implementation being used; or use something radically different from your run of the mill Turing machine, such as a quantum computer. Otherwise, you simply have too many possibilities to feasibly calculate; even with the fastest computers in the world, the Sun would run out of fuel long before you cracked even one 256bit AES message.
The last one is different, because it actually fucking works (as demonstrated by this story) while the other two just slightly annoy people.
Exactly; segradation is still in place in the US, women are not allowed to vote, India is still part of the British Empire, and slavery is still common practise in much of the world. In restrospect, it was naive of figures such as Mahatma Gandhi or Martin Luther King to suppose that non-violent protest and legal action would ever change the course of history.
Note that DansGuardian is GPL but claims to be proprietary.
The summary on the copyright page is certainly misleading, but a more detailed examination of the page throws up some explanation of this:
For all commercial[2] use, upon your downloading, DansGuardian 2 is licensed under the GPL, however permission to download DansGuardian from this, or any mirror[3], website is restricted.
...
[3] Mirror website: Includes only official mirrors listed on the 'Mirrors of this site' page.
There's also an entry in the FAQ:
So, if Debian puts DG on their website, they have to restrict downloads to non commercial users, right?
No, not right. Once you have a copy of a GPL app, no one can put any (non-GPL) restrictions on it - not even me the author. I can ask people to pay for downloading DG, but once its left this site it is under the GPL which means it is free (as in freedom) and free (as in beer - provided they want to give it away for free).
In other words, a commercial entity is allowed to download DansGuardian once from the official website, but once they have a copy then they have all the rights afforded by the GPL. Or, to put it another way, the commercial restrictions only govern what users can download from the website, and not the software provided. The GPL does not say you have to distribute your software to everyone who asks, so in this respect the GPL is not broken.
However, this is not exactly clear from the summary, and is a very peculiar way of doing things.
Ah, but over a darknet, he could have safely and anonymously admitted to reading it!
Okay, that made me chuckle:)
But would he believe that such a darknet was safe? The premise of Digital Fortress is that the NSA has constructed a supercomputer so powerful, it can brute force any encrypted message in minutes! Seriously, if you want a good laugh I recommend skimming the book, or at least taking a look at the Wikipedia page.
But more importantly, I'm just sick to death of kids who spend $30/week on overpriced coffee, and while drinking it with their friends bitch about how their favorite performers have the gall to have their life's work sold for a dollar or less per song.
Then clearly that market rates having coffee with friends as a more desirable produce than a three minute song on their iPods. However, since music nowadays costs virtually nothing to distribute, you should be making a far greater profit per item sold than the local Starbucks.
Well, at least you would be making a far greater profit, if the record labels and distributers didn't take a 90% cut from your work (the average for iTunes). Unless copyright infringement is responsible for more than a 90% revenue loss, then teenage immorality is not your biggest problem.
As for JAVA, it *is* a toy programming language. Any language that attempts to force a coding style upon users is meant for the beginner programmer, or student.
In the words of Inigo Montoya: You keep using that word. I do not think it means what you think it means.
You could argue that Java is badly designed, but given Java's widespread use on the server, I don't see how you could call it a "toy language". That implies it isn't used much in the real world, when in fact it's one of the most widely used languages to date. For instance, try googling "Java developer" and then "C developer".
As for virtual machines, they are there for a reason, to keep the novice from doing anything stupid, but it comes at a massive performance penalty.
It depends what you mean by "massive". Java's around twice or three times slower than C; but it's a linear speed decrease. If you double the complexity of the program, the gap between Java and C will remain at approximately the same ratio. In terms of Moore's Law, a top of the range computer running a Java application will be about as fast as a two year old computer running a C application. In terms of hardware cost, the price of an extra server is insignificant for businesses, compared to the cost of labour needed to produce the application. In this respect, the virtualisation overhead is insignificant for Java's main market.
One can spend years studying high level languages constructs without touching the low level details. Just because a programmer doesn't know what is "really happening behind the scenes", doesn't automatically imply that they are not a skilled and experienced developer. My contention is that learning programming in an abstract sense, i.e. taking a problem and producing a good solution in code, is more generally more important than learning about low level systems. In my experience, this is far more of a problem than lack of low level knowledge.
Efficiency and ease of debugging is one thing, but if you don't know how to effectively design software in the abstract sense, then no amount of low level knowledge will help you. And as I've remarked previously, there's a lot less use for low level knowledge in high level languages that remove themselves as far as possible from the internal workings of the system they execute upon.
But I hold the (easily accepted) opinion that a real software engineer knows much more than what you learn in 2 weeks of a crappy programming course.
Okay... But what does that have to do with the discussion? We were discussing high level languages, not crappy two week programming courses. If you accept that high level languages are not the sole domain of crappy two week programming courses, then I fail to see the connection. What point are you trying to make, exactly?
But we were talking about the education of engineers, not some damn "Learn Web Programming in 2 weeks" course...
Oh dear. Let me guess; you have no substantial experience with either Python or Ruby, and yet you hold the opinion that they are not languages suitable for use by "real" software engineers. Am I close?
Interface calls are about 4 times slower than normal method calls, and about 2 times slower than virtual method calls.
Which is useful to know, but not essential.
I agree that it's a good idea to know something about the low level details of a computer. However, such low level details become increasingly irrelevant the more abstract the language you use. Once you start using Python or Ruby, then the level of abstraction is so high that I can't see any advantage to knowing the low level details.
Concepts such as mutual exclusion, semaphones, and other abstract computer science concepts are only low level if you implement them in a low level language. So sure, a implementation of them might be, but only in a language that is not particular very high level. For instance, C# has primatives and pointers, and differentiates between at least three different types of method call. Sure, it runs off a platform independant virtual machine, but the level of abstraction in C# is still far lower than in a language like Python.
Boost::Lambda is primarily seriously scary template magic.
I need to look into template magic. I've heard you can do some pretty interesting things with them, but I haven't yet got around to reading up on the more complex uses of them.
I suspect not, since C++ constructors are not inherited
Er, yes they are.
So they are. That's odd. I wonder where I got the impression that they weren't.
Consider the contrary case of Erlang, which is actually (in my opinion) more suitable for web development than C++ or Java or PHP or perl or whatever. I'm still not going to make examples in it, simply because nobody speaks Erlang, so the example wouldn't be useful to almost anyone.
Bah, I'll have to go out and read up on Erlang, now:)
C++ is just a good example language because everyone and their mother can read it. Pure and simple.
In my experience, understanding a complex program to the degree of being able to confidently make changes to it, takes significantly longer than learning a new programming language. Coincidentally, my next job will involve both.
Modelling and code generation tools have reached the point where they actually work. These tools can generate the same cookie-cutter/boiler-plate code as high-level languages.
The benefits of high level languages go far beyond boiler plate code. If you want these benefits, you need more than a basic code generation tool - you effectively need a compiler. Then the question becomes; does my Python-to-C compiler generate code that's any faster than native Python bytecode?
Ask someone the possible reasons behind the performance differences between calls to interface methods, virtual methods and regular methods in C#. Or ask why generics in C# can overcome the overhead of virtual method calls.
How much overhead are we talking about?
Or (regarding debugging now), ask how a mutex works and why it's needed.
I wouldn't class mutual exclusion as a low level concept. I'd class it as an abstract concept found in almost all languages that can deal with concurrent programming, whether they be high level or low level.
About higher level languages (for example, Python), some of those questions are still valid, but I'm not really an expert on any of them so I'll pass that one for someone else.
I don't think any of the questions you listed are valid (which the possible exception of mutex, which I don't see as a low level concept). For instance, in Python all methods are virtual, and there is no concept of interfaces. However, since you're not an expert in such languages, I'll take your advice and leave that for someone else:)
If programmers designed cars, there wouldn't be automatic transmissions. There'd probably even be all sorts of gauges displaying like fuel-pressure and things I don't understand about cars...
In much of the world, there aren't automatic transmissions. In much of Europe, automatics are rather rare. However, that's somewhat beside the point.
Look at any technology, and you'll see that initially there are more dials and buttons than strictly necessary. Early radios, for instance, had many dials that eventually merged into just two: frequency and volume. One can see similar trends with cars; witness the disappearence of the choke, and in some cases, the gear stick and clutch.
I think eventually we'll see computing technology become more simplistic. Unfortunately, it's probably all downhill from there, as after simplicity, the trend tends to be toward maximum features (witness the amount of buttons and gizmos on a modern radio, or the number of computerized buttons and gadgets loaded into new cars).
But yes, I agree with you broadly: the inmates are running the asylum, to borrow a title from a relevant book. However, I don't think that's the primary reason for software sucking. Remember that shrink-wrapped, off-the-shelp desktop software makes up only a minority of the software industry.
Ultimately, I'd say not knowing what happens behind the abstractions is bad. I know (or can at least easily research and think about) everything what happens behind every line of.NET or Java code that you show me, and that is crucial for understanding debugging and optimization techniques.
Can you give me an example? Can you give me an example in a more abstracted language than.NET or Java?
Slashdot Mirror
Maybe I'm too naive :(
Yep, presumably artists will still need outside help to help them finance, organise and arrange large live gigs. However, I think there's less of a need for recording companies to market and distribute music from artists. Distributing music via the Internet is obviously cheap enough not to need financial backing; I need hardly go into the details of that on Slashdot. But marketing music is also a industry I expect to decline in the next few years. Music is an odd thing, in that one cannot 'sell' a piece of music in the same way one would sell a car. The customer either likes the piece of music he hears, or he does not. No amount of salesmanship will get him to change his mind, as it boils down to personal preference.
Because of this, marketing music consists largely of getting people to listen to it. Unfortunately, people have limited time on their hands, and cannot listen to every piece of music, so recording companies market selectively, using bands they know have a wide appeal. It's a broad, scattergun approach, and I can't help but think that one could do a far better job with a large database and some social networking software.
I'd say that was last generation. Puppet shows are passive entertainment, and the nearest modern equivalent to that is television. A not insignificant proportion of time that would have in the past been spent watching TV, is now spent on playing video games. Whether interactive electronic entertainment is better than passive is debatable, but is there any evidence that it's any worse?
I disagree. The Internet is a worldwide network of computers; it's unlikely that we'll stop needing to use computers, or stop needing to network them any time soon. It is probable that eventually the protocols and methods of transporting information will change, but the Internet itself is too broad a concept to come to an end due to technological progress in the near future.
There's never any proof per se in science. There have been, however, many experiments, observations and measurements of cosmic rays since they were discovered in 1912. In 1954, MITT used 11 scintillation detectors to measure the energy spectrum of cosmic rays, and found it to extend beyond 1e20 eV. To put that into perspective, our largest particle accelerator, the Tetravon Accelerator at CERN, can only manage 1e12 eV. We'd need over 100 million times the power to start getting beyond the capability of cosmic rays, which is a pretty comfortable margin in my book :)
You've already said that Toy Story is the exception to your generalisation about Pixar movies, but I can't see how you consider Nemo to fit. There is no "hero (who is known to be great)", and there is no particular event that "forces him to reprove that greatness", nor does any protagonist in the film meet and marry the "only cute single female in the movie".
Nor does the Incredibles fit your generalisation by any stretch of the imagination, and Monsters Inc. doesn't tie in well, either. Indeed, the only movie that seems to fit is Cars; no other movie Pixar movie comes close.
I recommend you watch the Incredibles, by the way; it's easily one of the best movies Pixar have produced.
Primary cosmic rays impact the earth all the time, and these often have far higher energies than even our largest particle accelerators are capable of producing. For any experiment we attempt, we can be reasonably sure that colliding cosmic rays have already produced the same results, sometime within the past few billions years. If we could create massively destructive black holes through our particle accelerators, one would expect that stray cosmic rays would have already done so.
It's not required to route Tor traffic from other users in order to make use of Tor. In order to serve as a Tor router, you need to download, setup and configure a separate Tor server package. The Tor client package just makes use of the Tor servers already available.
Raw power alone cannot overcome modern encryption. One either has to find a flaw in the encryption algorithm, or the implementation being used; or use something radically different from your run of the mill Turing machine, such as a quantum computer. Otherwise, you simply have too many possibilities to feasibly calculate; even with the fastest computers in the world, the Sun would run out of fuel long before you cracked even one 256bit AES message.
Exactly; segradation is still in place in the US, women are not allowed to vote, India is still part of the British Empire, and slavery is still common practise in much of the world. In restrospect, it was naive of figures such as Mahatma Gandhi or Martin Luther King to suppose that non-violent protest and legal action would ever change the course of history.
The summary on the copyright page is certainly misleading, but a more detailed examination of the page throws up some explanation of this:
There's also an entry in the FAQ:
In other words, a commercial entity is allowed to download DansGuardian once from the official website, but once they have a copy then they have all the rights afforded by the GPL. Or, to put it another way, the commercial restrictions only govern what users can download from the website, and not the software provided. The GPL does not say you have to distribute your software to everyone who asks, so in this respect the GPL is not broken.
However, this is not exactly clear from the summary, and is a very peculiar way of doing things.
Okay, that made me chuckle :)
But would he believe that such a darknet was safe? The premise of Digital Fortress is that the NSA has constructed a supercomputer so powerful, it can brute force any encrypted message in minutes! Seriously, if you want a good laugh I recommend skimming the book, or at least taking a look at the Wikipedia page.
Then clearly that market rates having coffee with friends as a more desirable produce than a three minute song on their iPods. However, since music nowadays costs virtually nothing to distribute, you should be making a far greater profit per item sold than the local Starbucks.
Well, at least you would be making a far greater profit, if the record labels and distributers didn't take a 90% cut from your work (the average for iTunes). Unless copyright infringement is responsible for more than a 90% revenue loss, then teenage immorality is not your biggest problem.
In the words of Inigo Montoya: You keep using that word. I do not think it means what you think it means.
You could argue that Java is badly designed, but given Java's widespread use on the server, I don't see how you could call it a "toy language". That implies it isn't used much in the real world, when in fact it's one of the most widely used languages to date. For instance, try googling "Java developer" and then "C developer".
It depends what you mean by "massive". Java's around twice or three times slower than C; but it's a linear speed decrease. If you double the complexity of the program, the gap between Java and C will remain at approximately the same ratio. In terms of Moore's Law, a top of the range computer running a Java application will be about as fast as a two year old computer running a C application. In terms of hardware cost, the price of an extra server is insignificant for businesses, compared to the cost of labour needed to produce the application. In this respect, the virtualisation overhead is insignificant for Java's main market.
I wouldn't admit to having read that particular trainwreck if I were you ;)
One can spend years studying high level languages constructs without touching the low level details. Just because a programmer doesn't know what is "really happening behind the scenes", doesn't automatically imply that they are not a skilled and experienced developer. My contention is that learning programming in an abstract sense, i.e. taking a problem and producing a good solution in code, is more generally more important than learning about low level systems. In my experience, this is far more of a problem than lack of low level knowledge.
Efficiency and ease of debugging is one thing, but if you don't know how to effectively design software in the abstract sense, then no amount of low level knowledge will help you. And as I've remarked previously, there's a lot less use for low level knowledge in high level languages that remove themselves as far as possible from the internal workings of the system they execute upon.
Okay... But what does that have to do with the discussion? We were discussing high level languages, not crappy two week programming courses. If you accept that high level languages are not the sole domain of crappy two week programming courses, then I fail to see the connection. What point are you trying to make, exactly?
Oh dear. Let me guess; you have no substantial experience with either Python or Ruby, and yet you hold the opinion that they are not languages suitable for use by "real" software engineers. Am I close?
Which is useful to know, but not essential.
I agree that it's a good idea to know something about the low level details of a computer. However, such low level details become increasingly irrelevant the more abstract the language you use. Once you start using Python or Ruby, then the level of abstraction is so high that I can't see any advantage to knowing the low level details.
Concepts such as mutual exclusion, semaphones, and other abstract computer science concepts are only low level if you implement them in a low level language. So sure, a implementation of them might be, but only in a language that is not particular very high level. For instance, C# has primatives and pointers, and differentiates between at least three different types of method call. Sure, it runs off a platform independant virtual machine, but the level of abstraction in C# is still far lower than in a language like Python.
I need to look into template magic. I've heard you can do some pretty interesting things with them, but I haven't yet got around to reading up on the more complex uses of them.
So they are. That's odd. I wonder where I got the impression that they weren't.
Bah, I'll have to go out and read up on Erlang, now :)
In my experience, understanding a complex program to the degree of being able to confidently make changes to it, takes significantly longer than learning a new programming language. Coincidentally, my next job will involve both.
Insofar as neither a C compiler nor a C++ compiler is particularly trivial to construct, yes.
The benefits of high level languages go far beyond boiler plate code. If you want these benefits, you need more than a basic code generation tool - you effectively need a compiler. Then the question becomes; does my Python-to-C compiler generate code that's any faster than native Python bytecode?
How much overhead are we talking about?
I wouldn't class mutual exclusion as a low level concept. I'd class it as an abstract concept found in almost all languages that can deal with concurrent programming, whether they be high level or low level.
I don't think any of the questions you listed are valid (which the possible exception of mutex, which I don't see as a low level concept). For instance, in Python all methods are virtual, and there is no concept of interfaces. However, since you're not an expert in such languages, I'll take your advice and leave that for someone else :)
In much of the world, there aren't automatic transmissions. In much of Europe, automatics are rather rare. However, that's somewhat beside the point.
Look at any technology, and you'll see that initially there are more dials and buttons than strictly necessary. Early radios, for instance, had many dials that eventually merged into just two: frequency and volume. One can see similar trends with cars; witness the disappearence of the choke, and in some cases, the gear stick and clutch.
I think eventually we'll see computing technology become more simplistic. Unfortunately, it's probably all downhill from there, as after simplicity, the trend tends to be toward maximum features (witness the amount of buttons and gizmos on a modern radio, or the number of computerized buttons and gadgets loaded into new cars).
But yes, I agree with you broadly: the inmates are running the asylum, to borrow a title from a relevant book. However, I don't think that's the primary reason for software sucking. Remember that shrink-wrapped, off-the-shelp desktop software makes up only a minority of the software industry.
Can you give me an example? Can you give me an example in a more abstracted language than .NET or Java?