``If it's not on Redbox for $1 or Hulu for free I'm not going to watch it. Now if only I could get the rest of the world to do that too maybe the MPAA would really be worried.''
Good luck with that. I live in the Rest of the World, and there is neither Redbox nor Hulu access here.
Meanwhile, I like to actually watch movies in the cinema. It's just more impressive, and it's nice to go out with someone that way.
``It's all nice and all, but if open video technology really wants to win, they have to be technically better. There is no other way.''
I don't think it helps. Vorbis was better than MP3 for years, but never managed to dethrone it.
Rather, I think what a format needs to succeed is enough backing. Proprietary formats always have some organization pushing them. What they do is go out and convince as many people and organizations to start using the format. If they succeed, people will have invested so much in the format that they won't abandon it. At that point, providing support for the format becomes a selling point, so you will see hardware and software vendors adding support to their products and listing it on the front of the box they put around their products.
The same thing works for open formats.
The problem is: large, powerful, and wealthy organizations that would be good backers for a format usually decide not to back an open format, because a proprietary format, especially one they own, gives them more control, and thus more opportunity to make money. Hence you see Apple pushing AAC with their own, proprietary DRM, Microsoft pushing WMA with their own proprietary DRM, but neither providing support for Vorbis in their products.
The same is happening in the video codec world. It's not about quality, it's about control. People are rallying behind Theora because it's free, and large organizations have been pushing H.264 because it's not free. Of course, H.264 has been pushed for a while, and quite successfully, so there is already widespread support for it.
The way I see it is that the world is large enough for more than one codec. If people want to use a proprietary codec, I am fine with that. On the other hand, I want people to be aware of the legal obstacles surrounding proprietary codecs, and related things, such as protocols and file formats. Standardizing on free codecs, protocols, and file systems means that everyone gets the opportunity to participate. Standardizing on proprietary codes, file systems, and file systems means you are reducing the choices available to those who would interact with your system. You would be creating lock-in and/or putting a legal and/or financial burden on people. How burdensome this is varies from case to case, but it's important to recognize the effect, and organizations ought to consider if they can responsibly impose such limits. I think it's wrong for governments to publish materials in proprietary formats, for example.
With all that in mind, I am glad that people and organizations are campaigning for freedom. I bear H.264 no ill will, but until it becomes free (as in freedom), I hope organizations will offer media in free formats as well as or instead of H.264.
Thanks for pointing that out. Perhaps I should have mentioned this in my earlier post.
I am aware that most of the language I found fault with comes straight from TFA, but I consider that tangential. Just because Time does it does not mean Slashdot should do it, too. The point is: I would like Slashdot to focus on concepts and intellectual discussion, not insults and mud-slinging. Whether the noise comes from the slashdotter or from somewhere else is irrelevant to me - I don't want it here, unless, of course, it is the subject of the discussion.
I have been reading and posting on Slashdot for years. The reason I have stuck around for so long is that I appreciate Slashdot as a place where interesting discussions take place. There are many sites on the World Wide Web where everyone is free to comment, but Slashdot stands out from the crowds by making interesting and well-worded messages visible amid the quagmire of nonsense, insults, spam, and other noise people are bound to post to public fora.
The summary posted for this story, unfortunately, is full of slanted wording. Without wanting to defend the RIAA and the MPAA or their business practices, I will simply note that calling them "MAFIAA" or claiming their business models "have changed little since the Mesozoic Era" is not very conductive to having a civilized discussion. Since having or witnessing such a discussion is what I come to Slashdot for, summaries such as the present one are not up to the standards I like Slashdot to aspire to.
Let's have discussions based on rational arguments, so that we may all benefit from what everybody has to say. Insults buy us nothing. Moderators mod down comments that consult them, and I would like for the editors to not post summaries that contain them. If the story is interesting, someone can submit a summary without such or other noise.
Thank you for your consideration, and please keep Slashdot above the level of other fora.
From the very beginning, in fact. Microsoft got started by Gates and Allen saying that they were working on a BASIC interpreter for the Altair 8800, when, in fact, they neither had the hardware nor were writing code for it. That is to say, Microsoft made vaporware even before it was founded.
I think China has been smallpoxing and is now transitioning from the civilization which everyone took pity on because they obviously weren't up to much -- to the new superpower which has all the other players go "WTF, how did that happen??"
Then, with railroads, they can move their units across the continent in a single turn, _and_ ramp up their production. And because their units can be wherever they need them, they'll need fewer of them, allowing them to ramp up their production even more (they do have one shield upkeep under Communism, after all), and, before you know it, they'll either have conquered the world or won the space race.
Yeah, I'll save my game and turn off the computer now.
It's interesting that nobody else seems to have said it yet, but here goes:
What I avoid when working on open source projects is packaging. I'll do design. I'll write documentation. I'll write the code. I'll find and fix bugs. I'll communicate with users. I'll make it as easy as I know how to to get the program working on your system.
But I avoid making a package for any one particular system.
It would probably greatly improve how easy it is to get started with a particular program, but I still can't seem to get myself to do it. Whenever I create a package, it always feels like I'm taking sides, like the platform I'm making a package for is somehow more favored by me than other platforms. And the few times I have created packages, they have not been included in any of the canonical repositories. So nowadays, I pretty much don't bother anymore.
Even though I think that, detach, in particular, would really make a great addition to every Unix-like operating system.
Interesting you should mention the installation process. The secret is that open source actually tends to do a much better job there than proprietary software. You just happen to have had the misfortune of only having used the two major platforms where this isn't the case.
Allow me to expand. On both Windows and OS X, the installation process is basically "get the binaries from somewhere (CD, website, what have you), dump them on your computer, and if there is an installer, run it". Rinse and repeat for every dependency that isn't bundled with the thing you are actually installing.
This is, as you have obviously found, very tedious and annoying.
The solution in the closed source world is to (1) bundle as much as possible with the operating system (hence you get > 10 GB OS installs) and (2) bundle everything else with the product you're distributing. With luck, this means that you only need to fetch one file and run at most one installer.
The disadvantage of this approach is that you end up using up lots and lots of disk space, and usually have multiple different versions of the same libraries on the same system. Which wastes more space, and, in the worst case, causes the dreaded "DLL hell", where multiple versions of a library have the same identifier, and programs that depend on one or the other version may end up getting the wrong version and not working.
With open source, the solution is to let the maintainers of the operating system package the software and integrate it with their system. When this works (and nowadays, that is on all major Linux distros and *BSDs), it means that installing software is just running a simple command (or clicking a few widgets in a GUI, if you prefer), and you will automatically get all the necessary dependencies pulled in and installed, as well. No more dependency hell, a lot less space wasted (I have _never_ operated a system where the OS partition had more than 10 GB on it), and everything tailored to your OS.
Now, what you have run into is software developed with an open source operating system in mind, but installed on a proprietary operating system without automatic dependency resolution. That means that, basically, neither solution is implemented, and you have to go and do the dependency resolution by hand. Yuck. I feel your pain.
The good news is that you can get a package manager with dependency resolution on OS X. Back when I still used it, there was a choice of pkgsrc, DarwinPorts, and fink. This is several years ago, so there may be more or fewer choices nowadays. Perhaps one of those can easy the pain. Good luck!
``Pascal has a is very simple and clear syntax and semantics. It has strong and static typing, making many errors very easy to catch at compile time. The case for Java is similar but the syntax and semantics are a bit more complicated.''
"A bit more complicated"? Java has grown to where any real-world program involves so many concepts that I wouldn't burden a beginning programmer with that. It's widely used and seems to be here to stay, so if the contest allows multiple languages, I think Java should certainly be one of them, but I sure hope it wouldn't be the only language allowed. It's just too complex.
``Its only real drawback is that it's a proprietary language. That won't effect the contest.''
You mean requiring kids to install a huge blob of closed-source software just so they can participate in the contest isn't a problem? Perhaps you don't have a problem with that, but I do. I don't think it's right to force software on people, much less if there are other languages you could choose that leave the kids free to choose the implementation they want to use.
``And in Python if the CPU is your constraint - which it isn't in most programs - then you write that little bit of CPU code in C or C++ and call that one part from Python. This keeps the rest of the program easy to debug and portable.''
While this is certainly a good point, I have found that, in practice, most programs fall in one of two categories:
1. CPU usage isn't much of a problem. Python is a great choice.
2. The bulk of your program needs to be _fast_. This practically rules out current Python implementations.
In the second case, you could still write the rest of your program in Python, but it isn't always clear that this is a good idea. You would be pulling in a dependency on a specific implementation of a pretty bulky library (no Python implementation I know of is really small, and compatibility of the foreign function interface isn't great between different implementations, and I'm not even sure about different versions of the same implementation).
There are, of course, also cases where you can write most of your program in Python and small parts in different languages, but I find those cases to be relatively rare.
Also, paid developers do the tasks they are assigned, but that doesn't mean the tasks get done well. And if they are not assigned a task, paid developers will often not do it (if they did, they would be wasting money, after all).
So what you see in practice is that, for commercial development, when things get tight, everything besides coding gets dropped, and the code gets sloppy.
But you are right. Volunteer efforts usually end when the volunteers lose interest. That's usually before a complete solution has been implemented.
The funny thing is that I don't know how memory management works in BASIC. It somehow never really seemed to be an issue. Even in assembly I didn't seem to have to think about it a lot. It's only when I started to program in C that I really woke up to the issues. Granted, all that is _way_ before I actually had the opportunity to take any classes on programming and programming languages.
But now I am curious. How _did_ memory management work on those old BASICs?
``Sure, we generally don't know the whole widget from top to bottom, but it's a hell of a lot easier to get a program up and running. It's not just frameworks either - the choice of languages we have today beats the crappy BASIC we had then, or the assembly language tools we had.''
I actually have a different perspective on that.
It used to be that your computer came with a BASIC implementation easily accessible. Since BASIC is also very easy to get started with, getting started with programming was very, very easy.
Nowadays, getting started with programming is often much harder. Many computers don't ship with development tools anymore. Many languages in common use are quite a bit harder to get started with (how many concepts are in your Hello World in BASIC, and how many in Java?). You will also typically have to choose from among the myriad of libraries and frameworks, or get the choices forced upon you, and you will have to learn the concepts employed in those, too. And whereas it was normal back in the day to know how your computer actually worked, only a fraction of programmers know this nowadays - a situation which is not helped by hardware manufacturers actually refusing to disclose it to you.
It's not all doom and gloom, but there are certainly things that were better back in the day. It certainly seems to me that both the barrier to entry and the amount of effort you had to put in to really know all the ins and outs was lower in the home computer era than it is now.
``it makes Obama with his promises of an open government look more than just stupid. It makes him look Bush.''
I'm not sure that's the wisest wording you could have used. How many secret laws did Bush pass, anyway? But the more important thing is, I don't want to know how Obama does in comparison to Bush. I want to know how he does in his own right.
Call me a fundamentalist, but the last thing I want from an IDE is to further obscure the way code relates to files. When programming, I want to know what I am doing. I want to know how the project is structured, I want to know how I can do things _without_ the software that I happen to be using at the moment. That way, I can switch software at some point, and/or automate things.
That said, I am all for innovation, and I'm also all for innovation in IDEs. I'm curious to see how this goes.
``Sure, if you have a full Linux environment with gcc, man pages, and web access then BASIC is just some lame toy, but if it's all you have It's a start.''
Yes.
And, frankly, I would rather not teach someone their first programming steps using C on Linux. For a first language, I want them to have to learn as few concepts as possible before they can do something. Include files, the whole boilerplate for main, pointers, and the edit-compile-test cycle are just too much. I want them to be able to type in a single line and have it work.
At the next step up, I think I would prefer a language without too much magic happening behind the scenes. Automatic memory management is wonderful, but I want my hypothetical programming students to realize that everything has a cost, and objects don't just come out of nowhere and go away when you don't need them anymore. The same applies to a lot of other things, even function calls and the humble "i = i + 1".
Considering the above two things, it looks like my students would learn at least one reasonably high-level, but, more importantly, interactive language, and at least some sort of assembly language. The first, to get into programming at all, and the second to really understand what is happening inside the computer.
After that, it would be the bread and butter of programming: abstractions, abstractions, abstractions. Unless you are unfortunate enough to code for an assembler with no macro support, or a language like the original COBOL, you will write your program by taking what the language gives you and using it to create abstractions that fit the problem you are solving. This is where you create your functions, your macros, your data structures, your objects, your rules, and any other abstraction you may need so that the tools you have fit the problem space. In the process, you will come across the various programming paradigms: structured programming, object-oriented programming, functional programming, declarative programming, etc. I think this should ideally be done using a language in which all the concepts can be expressed. Unfortunately, few languages can do this well.
Once you reach this stage, you know a lot of things that will come in useful in programming in general, but there is still a lot left to learn. You will need to learn the specifics and the libraries of the languages you will be using. For example, if you are going to program in C, you will need to understand pointers and dereferencing. You will need to learn common pitfalls and how to avoid them. Concurrency should be a big item here. You will have to learn how to write maintainable code. You will have to learn about efficiency - how to write efficient code, but, more importantly, how to spend your time efficiently.
And that's just for programming. To be a good programmer, you will also have to learn related disciplines, such as design, documentation, communication, and version control.
But the first step is that first program. Nobody will ever succeed in climbing the mountain without taking the first step. And if we want people to climb the mountain, that first step had better be easy.
In my opinion, the old BASICs, with line numbers and gotos, aren't half bad for the first step. They are easy to get started with and yet pretty close to the fundamentals of your computer. I would be interested in hearing better suggestions, though. Especially since they may help avoid the risk of people who never made it past the first step writing serious projects in BASIC...
As for me, I started with IBM BASIC (first step), then did x86 assembly (fundamentals), then C (because people told me that's what real programmers use) and PHP because I had to use it at work, then Java (because the propaganda convinced me that it was the Messiah among programming languages), and then I realized I shouldn't just listen to other people, but also do my own research and draw my own conclusions. Since then, I have learned many programming languages just to learn about the concepts i
I think you sort of have to cultivate your own myth if you want to become famous. There are a lot of brilliant people out there who most people have never heard of. Dijkstra made great contributions to computer science and programming, but to say that that is what made him famous belittles the work of all those others who did so, too. He was famous because he made great contributions _and_ worked on his visibility.
Being famous is not one of my goals, so I don't engage in a lot of activities that would raise my visibility. In fact, I sometimes feel I work on my visibility too little - other people get asked for things that I would have been a better fit for, simply because people know them and not me. On the other hand, I don't claim to be anywhere near as good as Dijkstra. He changed the world in a way that I likely never will.
I feel sorry for everyone who bought the game and couldn't play it. I hope they learn from this experience and inform themselves before making a purchase in the future. The reason they can't play this game is because it has been crippled by DRM. I also hope they will look around and see the wide scope of DRM. It's not just this game, it's many other games, as well. It's on movies on Bluray discs and DVDs. It's in the music sold by iTunes. It's in a lot of popular PC software, such as Microsoft Windows.
But it's not too late. There are alternatives. There is software that does not include DRM. There is even software that allows you to do most anything you might wish to do with it, including giving out copies to all your friends. There is music without DRM. Music that comes on actual CDs is DRM-free (beware of things that look like CDs but aren't, though). And, as with software, there is music that you are allowed to distribute to your friends, or even sample and modify to your own taste. In a limited sense, the same goes for movies. DRM-free movies are few and far between.
Slashdot Mirror
``If it's not on Redbox for $1 or Hulu for free I'm not going to watch it. Now if only I could get the rest of the world to do that too maybe the MPAA would really be worried.''
Good luck with that. I live in the Rest of the World, and there is neither Redbox nor Hulu access here.
Meanwhile, I like to actually watch movies in the cinema. It's just more impressive, and it's nice to go out with someone that way.
``It's all nice and all, but if open video technology really wants to win, they have to be technically better. There is no other way.''
I don't think it helps. Vorbis was better than MP3 for years, but never managed to dethrone it.
Rather, I think what a format needs to succeed is enough backing. Proprietary formats always have some organization pushing them. What they do is go out and convince as many people and organizations to start using the format. If they succeed, people will have invested so much in the format that they won't abandon it. At that point, providing support for the format becomes a selling point, so you will see hardware and software vendors adding support to their products and listing it on the front of the box they put around their products.
The same thing works for open formats.
The problem is: large, powerful, and wealthy organizations that would be good backers for a format usually decide not to back an open format, because a proprietary format, especially one they own, gives them more control, and thus more opportunity to make money. Hence you see Apple pushing AAC with their own, proprietary DRM, Microsoft pushing WMA with their own proprietary DRM, but neither providing support for Vorbis in their products.
The same is happening in the video codec world. It's not about quality, it's about control. People are rallying behind Theora because it's free, and large organizations have been pushing H.264 because it's not free. Of course, H.264 has been pushed for a while, and quite successfully, so there is already widespread support for it.
The way I see it is that the world is large enough for more than one codec. If people want to use a proprietary codec, I am fine with that. On the other hand, I want people to be aware of the legal obstacles surrounding proprietary codecs, and related things, such as protocols and file formats. Standardizing on free codecs, protocols, and file systems means that everyone gets the opportunity to participate. Standardizing on proprietary codes, file systems, and file systems means you are reducing the choices available to those who would interact with your system. You would be creating lock-in and/or putting a legal and/or financial burden on people. How burdensome this is varies from case to case, but it's important to recognize the effect, and organizations ought to consider if they can responsibly impose such limits. I think it's wrong for governments to publish materials in proprietary formats, for example.
With all that in mind, I am glad that people and organizations are campaigning for freedom. I bear H.264 no ill will, but until it becomes free (as in freedom), I hope organizations will offer media in free formats as well as or instead of H.264.
Thanks for pointing that out. Perhaps I should have mentioned this in my earlier post.
I am aware that most of the language I found fault with comes straight from TFA, but I consider that tangential. Just because Time does it does not mean Slashdot should do it, too. The point is: I would like Slashdot to focus on concepts and intellectual discussion, not insults and mud-slinging. Whether the noise comes from the slashdotter or from somewhere else is irrelevant to me - I don't want it here, unless, of course, it is the subject of the discussion.
Dear editors,
I have been reading and posting on Slashdot for years. The reason I have stuck around for so long is that I appreciate Slashdot as a place where interesting discussions take place. There are many sites on the World Wide Web where everyone is free to comment, but Slashdot stands out from the crowds by making interesting and well-worded messages visible amid the quagmire of nonsense, insults, spam, and other noise people are bound to post to public fora.
The summary posted for this story, unfortunately, is full of slanted wording. Without wanting to defend the RIAA and the MPAA or their business practices, I will simply note that calling them "MAFIAA" or claiming their business models "have changed little since the Mesozoic Era" is not very conductive to having a civilized discussion. Since having or witnessing such a discussion is what I come to Slashdot for, summaries such as the present one are not up to the standards I like Slashdot to aspire to.
Let's have discussions based on rational arguments, so that we may all benefit from what everybody has to say. Insults buy us nothing. Moderators mod down comments that consult them, and I would like for the editors to not post summaries that contain them. If the story is interesting, someone can submit a summary without such or other noise.
Thank you for your consideration, and please keep Slashdot above the level of other fora.
Sincerely,
A Faithful Slashdotter
From the very beginning, in fact. Microsoft got started by Gates and Allen saying that they were working on a BASIC interpreter for the Altair 8800, when, in fact, they neither had the hardware nor were writing code for it. That is to say, Microsoft made vaporware even before it was founded.
I think China has been smallpoxing and is now transitioning from the civilization which everyone took pity on because they obviously weren't up to much -- to the new superpower which has all the other players go "WTF, how did that happen??"
Then, with railroads, they can move their units across the continent in a single turn, _and_ ramp up their production. And because their units can be wherever they need them, they'll need fewer of them, allowing them to ramp up their production even more (they do have one shield upkeep under Communism, after all), and, before you know it, they'll either have conquered the world or won the space race.
Yeah, I'll save my game and turn off the computer now.
Wow, that's some project. And China wants to fund it? That'll surely put them on the map as one of the world's superpowers.
It's interesting that nobody else seems to have said it yet, but here goes:
What I avoid when working on open source projects is packaging. I'll do design. I'll write documentation. I'll write the code. I'll find and fix bugs. I'll communicate with users. I'll make it as easy as I know how to to get the program working on your system.
But I avoid making a package for any one particular system.
It would probably greatly improve how easy it is to get started with a particular program, but I still can't seem to get myself to do it. Whenever I create a package, it always feels like I'm taking sides, like the platform I'm making a package for is somehow more favored by me than other platforms. And the few times I have created packages, they have not been included in any of the canonical repositories. So nowadays, I pretty much don't bother anymore.
Even though I think that, detach, in particular, would really make a great addition to every Unix-like operating system.
Interesting you should mention the installation process. The secret is that open source actually tends to do a much better job there than proprietary software. You just happen to have had the misfortune of only having used the two major platforms where this isn't the case.
Allow me to expand. On both Windows and OS X, the installation process is basically "get the binaries from somewhere (CD, website, what have you), dump them on your computer, and if there is an installer, run it". Rinse and repeat for every dependency that isn't bundled with the thing you are actually installing.
This is, as you have obviously found, very tedious and annoying.
The solution in the closed source world is to (1) bundle as much as possible with the operating system (hence you get > 10 GB OS installs) and (2) bundle everything else with the product you're distributing. With luck, this means that you only need to fetch one file and run at most one installer.
The disadvantage of this approach is that you end up using up lots and lots of disk space, and usually have multiple different versions of the same libraries on the same system. Which wastes more space, and, in the worst case, causes the dreaded "DLL hell", where multiple versions of a library have the same identifier, and programs that depend on one or the other version may end up getting the wrong version and not working.
With open source, the solution is to let the maintainers of the operating system package the software and integrate it with their system. When this works (and nowadays, that is on all major Linux distros and *BSDs), it means that installing software is just running a simple command (or clicking a few widgets in a GUI, if you prefer), and you will automatically get all the necessary dependencies pulled in and installed, as well. No more dependency hell, a lot less space wasted (I have _never_ operated a system where the OS partition had more than 10 GB on it), and everything tailored to your OS.
Now, what you have run into is software developed with an open source operating system in mind, but installed on a proprietary operating system without automatic dependency resolution. That means that, basically, neither solution is implemented, and you have to go and do the dependency resolution by hand. Yuck. I feel your pain.
The good news is that you can get a package manager with dependency resolution on OS X. Back when I still used it, there was a choice of pkgsrc, DarwinPorts, and fink. This is several years ago, so there may be more or fewer choices nowadays. Perhaps one of those can easy the pain. Good luck!
Super Mario:
http://www.youtube.com/watch?v=cdbs9N7x_3w
Err...crossover between Pong and the Matrix:
http://www.youtube.com/watch?v=-dcmDscwEcI
Tetris:
http://www.youtube.com/watch?v=4bekQU9l8hk
``Pascal has a is very simple and clear syntax and semantics. It has strong and static typing, making many errors very easy to catch at compile time. The case for Java is similar but the syntax and semantics are a bit more complicated.''
"A bit more complicated"? Java has grown to where any real-world program involves so many concepts that I wouldn't burden a beginning programmer with that. It's widely used and seems to be here to stay, so if the contest allows multiple languages, I think Java should certainly be one of them, but I sure hope it wouldn't be the only language allowed. It's just too complex.
``Its only real drawback is that it's a proprietary language. That won't effect the contest.''
You mean requiring kids to install a huge blob of closed-source software just so they can participate in the contest isn't a problem? Perhaps you don't have a problem with that, but I do. I don't think it's right to force software on people, much less if there are other languages you could choose that leave the kids free to choose the implementation they want to use.
``And in Python if the CPU is your constraint - which it isn't in most programs - then you write that little bit of CPU code in C or C++ and call that one part from Python. This keeps the rest of the program easy to debug and portable.''
While this is certainly a good point, I have found that, in practice, most programs fall in one of two categories:
1. CPU usage isn't much of a problem. Python is a great choice.
2. The bulk of your program needs to be _fast_. This practically rules out current Python implementations.
In the second case, you could still write the rest of your program in Python, but it isn't always clear that this is a good idea. You would be pulling in a dependency on a specific implementation of a pretty bulky library (no Python implementation I know of is really small, and compatibility of the foreign function interface isn't great between different implementations, and I'm not even sure about different versions of the same implementation).
There are, of course, also cases where you can write most of your program in Python and small parts in different languages, but I find those cases to be relatively rare.
``Python doesn't have a built-in JIT??''
Does have. Just that JIT compilation doesn't necessarily mean you are going to be winning speed contests.
``What's with all the Perl hate, then?''
What's that got to do with anything?
%s/open source/volunteer-developed/ig
Also, paid developers do the tasks they are assigned, but that doesn't mean the tasks get done well. And if they are not assigned a task, paid developers will often not do it (if they did, they would be wasting money, after all).
So what you see in practice is that, for commercial development, when things get tight, everything besides coding gets dropped, and the code gets sloppy.
But you are right. Volunteer efforts usually end when the volunteers lose interest. That's usually before a complete solution has been implemented.
There's the Commentator for that.
Anybody have an implementation of that for *nix?
``1/pi is not pi.''
pi r square!
No, pies are round!
The funny thing is that I don't know how memory management works in BASIC. It somehow never really seemed to be an issue. Even in assembly I didn't seem to have to think about it a lot. It's only when I started to program in C that I really woke up to the issues. Granted, all that is _way_ before I actually had the opportunity to take any classes on programming and programming languages.
But now I am curious. How _did_ memory management work on those old BASICs?
``Sure, we generally don't know the whole widget from top to bottom, but it's a hell of a lot easier to get a program up and running. It's not just frameworks either - the choice of languages we have today beats the crappy BASIC we had then, or the assembly language tools we had.''
I actually have a different perspective on that.
It used to be that your computer came with a BASIC implementation easily accessible. Since BASIC is also very easy to get started with, getting started with programming was very, very easy.
Nowadays, getting started with programming is often much harder. Many computers don't ship with development tools anymore. Many languages in common use are quite a bit harder to get started with (how many concepts are in your Hello World in BASIC, and how many in Java?). You will also typically have to choose from among the myriad of libraries and frameworks, or get the choices forced upon you, and you will have to learn the concepts employed in those, too. And whereas it was normal back in the day to know how your computer actually worked, only a fraction of programmers know this nowadays - a situation which is not helped by hardware manufacturers actually refusing to disclose it to you.
It's not all doom and gloom, but there are certainly things that were better back in the day. It certainly seems to me that both the barrier to entry and the amount of effort you had to put in to really know all the ins and outs was lower in the home computer era than it is now.
``In exceptional conditions I would certainly include what the driver is wearing.''
I can see it now. Recall those drivers who called 911 when their vehicle accelerated out of control?
Driver: Help! My car is accelerating out of control!
911-person: What are you wearing?
``it makes Obama with his promises of an open government look more than just stupid. It makes him look Bush.''
I'm not sure that's the wisest wording you could have used. How many secret laws did Bush pass, anyway? But the more important thing is, I don't want to know how Obama does in comparison to Bush. I want to know how he does in his own right.
Call me a fundamentalist, but the last thing I want from an IDE is to further obscure the way code relates to files. When programming, I want to know what I am doing. I want to know how the project is structured, I want to know how I can do things _without_ the software that I happen to be using at the moment. That way, I can switch software at some point, and/or automate things.
That said, I am all for innovation, and I'm also all for innovation in IDEs. I'm curious to see how this goes.
``Sure, if you have a full Linux environment with gcc, man pages, and web access then BASIC is just some lame toy, but if it's all you have It's a start.''
Yes.
And, frankly, I would rather not teach someone their first programming steps using C on Linux. For a first language, I want them to have to learn as few concepts as possible before they can do something. Include files, the whole boilerplate for main, pointers, and the edit-compile-test cycle are just too much. I want them to be able to type in a single line and have it work.
At the next step up, I think I would prefer a language without too much magic happening behind the scenes. Automatic memory management is wonderful, but I want my hypothetical programming students to realize that everything has a cost, and objects don't just come out of nowhere and go away when you don't need them anymore. The same applies to a lot of other things, even function calls and the humble "i = i + 1".
Considering the above two things, it looks like my students would learn at least one reasonably high-level, but, more importantly, interactive language, and at least some sort of assembly language. The first, to get into programming at all, and the second to really understand what is happening inside the computer.
After that, it would be the bread and butter of programming: abstractions, abstractions, abstractions. Unless you are unfortunate enough to code for an assembler with no macro support, or a language like the original COBOL, you will write your program by taking what the language gives you and using it to create abstractions that fit the problem you are solving. This is where you create your functions, your macros, your data structures, your objects, your rules, and any other abstraction you may need so that the tools you have fit the problem space. In the process, you will come across the various programming paradigms: structured programming, object-oriented programming, functional programming, declarative programming, etc. I think this should ideally be done using a language in which all the concepts can be expressed. Unfortunately, few languages can do this well.
Once you reach this stage, you know a lot of things that will come in useful in programming in general, but there is still a lot left to learn. You will need to learn the specifics and the libraries of the languages you will be using. For example, if you are going to program in C, you will need to understand pointers and dereferencing. You will need to learn common pitfalls and how to avoid them. Concurrency should be a big item here. You will have to learn how to write maintainable code. You will have to learn about efficiency - how to write efficient code, but, more importantly, how to spend your time efficiently.
And that's just for programming. To be a good programmer, you will also have to learn related disciplines, such as design, documentation, communication, and version control.
But the first step is that first program. Nobody will ever succeed in climbing the mountain without taking the first step. And if we want people to climb the mountain, that first step had better be easy.
In my opinion, the old BASICs, with line numbers and gotos, aren't half bad for the first step. They are easy to get started with and yet pretty close to the fundamentals of your computer. I would be interested in hearing better suggestions, though. Especially since they may help avoid the risk of people who never made it past the first step writing serious projects in BASIC...
As for me, I started with IBM BASIC (first step), then did x86 assembly (fundamentals), then C (because people told me that's what real programmers use) and PHP because I had to use it at work, then Java (because the propaganda convinced me that it was the Messiah among programming languages), and then I realized I shouldn't just listen to other people, but also do my own research and draw my own conclusions. Since then, I have learned many programming languages just to learn about the concepts i
I think you sort of have to cultivate your own myth if you want to become famous. There are a lot of brilliant people out there who most people have never heard of. Dijkstra made great contributions to computer science and programming, but to say that that is what made him famous belittles the work of all those others who did so, too. He was famous because he made great contributions _and_ worked on his visibility.
Being famous is not one of my goals, so I don't engage in a lot of activities that would raise my visibility. In fact, I sometimes feel I work on my visibility too little - other people get asked for things that I would have been a better fit for, simply because people know them and not me. On the other hand, I don't claim to be anywhere near as good as Dijkstra. He changed the world in a way that I likely never will.
I feel sorry for everyone who bought the game and couldn't play it. I hope they learn from this experience and inform themselves before making a purchase in the future. The reason they can't play this game is because it has been crippled by DRM. I also hope they will look around and see the wide scope of DRM. It's not just this game, it's many other games, as well. It's on movies on Bluray discs and DVDs. It's in the music sold by iTunes. It's in a lot of popular PC software, such as Microsoft Windows.
But it's not too late. There are alternatives. There is software that does not include DRM. There is even software that allows you to do most anything you might wish to do with it, including giving out copies to all your friends. There is music without DRM. Music that comes on actual CDs is DRM-free (beware of things that look like CDs but aren't, though). And, as with software, there is music that you are allowed to distribute to your friends, or even sample and modify to your own taste. In a limited sense, the same goes for movies. DRM-free movies are few and far between.