Spelling and grammar matter for example, a good fraction of the people who read your post, including a disproportionate number of the more educated ones, probably remember very little of your argument because they were busy trying to figure out your gratuitous capitalization scheme.
Object oriented programming is a nice organizational technique for larger programs and code reuse. It works well, if used properly, not least because it imposes a namespace system. Most OO systems also give you some neat automatic features like inheritance.
OO is not a silver bullet, not everything needs to be OO, and nobody, ever, should start learning programming with OO. If you make absolutely everything an object you're either an idiot or a Java programmer (no comment). If you make everything a templated class you're evil and a C++ programmer. If you reject all of OO because some people take it too far, you're no better than the other two.
OO does some cool things. Used properly, at the right time, it makes very nice code. Used badly, it makes a godawful mess.
Yes. And there are no shortage of toolkits, libraries, macros and personal styles that use C structs as objects.
They don't do inheritance so well though.
There's nothing wrong with C, and I greatly prefer C to the horror that is C++, but there ARE some things real objects do that are pretty nice in many circumstances. That's why it's nice that Objective-C (and C++ if you insist on doing that to yourself) are supersets of C, so you can happily mix non-object oriented C code and OO code however you like.
I got the impression it wasn't even that. Samsung has decided it looks like they're going to lose, so they've decided to retroactively drop a few features (does that seriously make a difference?) and they asked Google to help them. Google did.
"Google, Google, they made me do it! Help me hide this before Mom finds out!"
One of the big benefits of SDR is that it's able to use any set of frequencies you like. That means you need to have a high speed ADC and the ability to process those samples. That means a decent processor, special purpose or not (they use FPGAs in the boards mentioned in the article). Compare that with the simple oscillator and mixing circuits that are usually used.
Sure, you can use a DSP or other special purpose chip to produce the baseband signal (and that's what's often done), but that's not really what SDR is about.
I guess when I said "publish papers" I meant peer reviewed research papers, not company whitepapers. Microsoft usually has a decent amount of stuff in SIGGRAPH, and some of it turns into tech demos, but not much seems to transition into real products.
The TV dongle development makes the whole thing much more interesting. I took a look at GNURadio when it was a new project and lost interest because you couldn't actually do anything with it unless you were already a radio engineer with all the (expensive) equipment to make your own hardware.
Still, you have to find one of those dongles. Somebody really needs to design and manufacture a cheap board specifically for radio, like the Arduino people have done.
In reality, though, a phone that was able to do that would have to have a processor big enough to handle the extra overhead from decoding 4G, would burn through it's batteries in no time, and would be more expensive. And you wouldn't be able to do CB because you wouldn't have an appropriate antenna, although you probably could turn it into an FRS walkie talkie. There are already multi-frequency CDMA/GSM world phones chips. To support CDMA and GSM you need to have the identity module hardware for both anyway.
It might happen someday, but I think things like cell phones are the LAST place SDR is going to be used. Cell phones are already one of the only places you'll find dedicated media decoding chips, and for the same reason.
You can get start playing with Arduino for about $25. Less if you can program your own microcontrollers. GNURadio has so far been a software solution with no, or very expensive, hardware to go with it. Not that the Phi changes that, but it's a step in the right direction.
When you can buy a GNURadio setup, including hardware, for under $100, then it'll take off. When it gets down to $25 it will be as popular as Arduino.
Sage is basically a batteries included Python distribution. Lots of people like a bit package to use like that. I prefer putting the pieces together myself. My other complaint about Sage, last time I looked at it, is that it's more difficult to install your own packages in the Sage environment than it is to do so with stock Python. One of the great things about Python is needing a particular algorithm, typing it into Google, and downloading and installing the handy package that someone else has already written and shared.
I don't think it's going to do much for cell phones. Software defined radio basically shifts the processing from hardware to software. That requires power. For a cell phone, which must operate on a set protocol, there are only drawbacks. Yes, you could upgrade the protocol, but cell protocols don't change very fast and it's unlikely you'd want to run a general purpose cell tower on SDR because of the processing requirements.
What SDR is going to do is revolutionize the unlicensed bands.
"this seems like a relatively small collections matter, which would likely be handled by masses of demand letters for a period of time before an actual suit..."
Universities don't do collections. You pay what they think you owe, then you graduate. No money, no degree. The story smells funny, which almost always means that we don't know the whole story.
What does "legitimate data analysis tool" mean? MatLab was included in the comparison, and MatLab is more of an engineering tool. The built in (excuse me, optional paid for) stats library is pretty limited.
R is great for doing statistical analysis, but it's not great for doing things like image analysis. Without additional libraries R isn't nearly as good as it is with libraries either.
I wrote a general linear model in Python because I was unhappy with the existing ones and I wanted an intimate knowledge of how it worked. I wrote most of a general linear mixed model, but then decided it wasn't worth the time and just used the one in R via RPy2. Then it turned out the one built into R was too slow, so I upgraded to the one in the lme R package. That exists because a lot of smart people use R.
But sure, if your "data analysis" involves multiplication and maybe a t-test or two, it doesn't really matter what you use.
"News to me, to be honest. But in any case: we're quite some years later now. Maybe the Firefox phone won't be too late, but the iPhone was too early instead:P"
There are more recent examples. Even Facebook's crappy app is much better than their web app was. Google introduced a native API for Android. Chrome OS, and anything that used it, is dead.
If a Firefox phone doesn't support native apps, it will be DOA.
Slashdot Mirror
Spelling and grammar matter for example, a good fraction of the people who read your post, including a disproportionate number of the more educated ones, probably remember very little of your argument because they were busy trying to figure out your gratuitous capitalization scheme.
Amen. Linus is a pretty smart guy.
I think that falls under "you don't always need the language to hold your hand."
We got the Web? That's your argument?
Object oriented programming is a nice organizational technique for larger programs and code reuse. It works well, if used properly, not least because it imposes a namespace system. Most OO systems also give you some neat automatic features like inheritance.
OO is not a silver bullet, not everything needs to be OO, and nobody, ever, should start learning programming with OO. If you make absolutely everything an object you're either an idiot or a Java programmer (no comment). If you make everything a templated class you're evil and a C++ programmer. If you reject all of OO because some people take it too far, you're no better than the other two.
OO does some cool things. Used properly, at the right time, it makes very nice code. Used badly, it makes a godawful mess.
YES! Now, explain to me how you got past "C, a raw machine independent assembler-like language"?
Assembler-like? C? C used to be the hot new language that held your hand and did everything for you, unlike assembler. Now C is assembler-like?
Yes. And there are no shortage of toolkits, libraries, macros and personal styles that use C structs as objects.
They don't do inheritance so well though.
There's nothing wrong with C, and I greatly prefer C to the horror that is C++, but there ARE some things real objects do that are pretty nice in many circumstances. That's why it's nice that Objective-C (and C++ if you insist on doing that to yourself) are supersets of C, so you can happily mix non-object oriented C code and OO code however you like.
Don't forget, it's curved open water. As in, you can't see one point from the other.
I got the impression it wasn't even that. Samsung has decided it looks like they're going to lose, so they've decided to retroactively drop a few features (does that seriously make a difference?) and they asked Google to help them. Google did.
"Google, Google, they made me do it! Help me hide this before Mom finds out!"
Software defined radios can transmit as well....
One of the big benefits of SDR is that it's able to use any set of frequencies you like. That means you need to have a high speed ADC and the ability to process those samples. That means a decent processor, special purpose or not (they use FPGAs in the boards mentioned in the article). Compare that with the simple oscillator and mixing circuits that are usually used.
Sure, you can use a DSP or other special purpose chip to produce the baseband signal (and that's what's often done), but that's not really what SDR is about.
I guess when I said "publish papers" I meant peer reviewed research papers, not company whitepapers. Microsoft usually has a decent amount of stuff in SIGGRAPH, and some of it turns into tech demos, but not much seems to transition into real products.
The TV dongle development makes the whole thing much more interesting. I took a look at GNURadio when it was a new project and lost interest because you couldn't actually do anything with it unless you were already a radio engineer with all the (expensive) equipment to make your own hardware.
Still, you have to find one of those dongles. Somebody really needs to design and manufacture a cheap board specifically for radio, like the Arduino people have done.
In reality, though, a phone that was able to do that would have to have a processor big enough to handle the extra overhead from decoding 4G, would burn through it's batteries in no time, and would be more expensive. And you wouldn't be able to do CB because you wouldn't have an appropriate antenna, although you probably could turn it into an FRS walkie talkie. There are already multi-frequency CDMA/GSM world phones chips. To support CDMA and GSM you need to have the identity module hardware for both anyway.
It might happen someday, but I think things like cell phones are the LAST place SDR is going to be used. Cell phones are already one of the only places you'll find dedicated media decoding chips, and for the same reason.
Most phones already use chips that have wifi, bluetooth and GPS in one.
You can get start playing with Arduino for about $25. Less if you can program your own microcontrollers. GNURadio has so far been a software solution with no, or very expensive, hardware to go with it. Not that the Phi changes that, but it's a step in the right direction.
When you can buy a GNURadio setup, including hardware, for under $100, then it'll take off. When it gets down to $25 it will be as popular as Arduino.
Sage is basically a batteries included Python distribution. Lots of people like a bit package to use like that. I prefer putting the pieces together myself. My other complaint about Sage, last time I looked at it, is that it's more difficult to install your own packages in the Sage environment than it is to do so with stock Python. One of the great things about Python is needing a particular algorithm, typing it into Google, and downloading and installing the handy package that someone else has already written and shared.
Assembly, Fortran/Cobol/Pascal and C. They said veteran, right?
I don't think it's going to do much for cell phones. Software defined radio basically shifts the processing from hardware to software. That requires power. For a cell phone, which must operate on a set protocol, there are only drawbacks. Yes, you could upgrade the protocol, but cell protocols don't change very fast and it's unlikely you'd want to run a general purpose cell tower on SDR because of the processing requirements.
What SDR is going to do is revolutionize the unlicensed bands.
R is MUCH nicer when you use it through a bridge from Python.
"this seems like a relatively small collections matter, which would likely be handled by masses of demand letters for a period of time before an actual suit..."
Universities don't do collections. You pay what they think you owe, then you graduate. No money, no degree. The story smells funny, which almost always means that we don't know the whole story.
What does "legitimate data analysis tool" mean? MatLab was included in the comparison, and MatLab is more of an engineering tool. The built in (excuse me, optional paid for) stats library is pretty limited.
R is great for doing statistical analysis, but it's not great for doing things like image analysis. Without additional libraries R isn't nearly as good as it is with libraries either.
It depends how complicated the math is.
I wrote a general linear model in Python because I was unhappy with the existing ones and I wanted an intimate knowledge of how it worked. I wrote most of a general linear mixed model, but then decided it wasn't worth the time and just used the one in R via RPy2. Then it turned out the one built into R was too slow, so I upgraded to the one in the lme R package. That exists because a lot of smart people use R.
But sure, if your "data analysis" involves multiplication and maybe a t-test or two, it doesn't really matter what you use.
"News to me, to be honest. But in any case: we're quite some years later now. Maybe the Firefox phone won't be too late, but the iPhone was too early instead :P"
There are more recent examples. Even Facebook's crappy app is much better than their web app was. Google introduced a native API for Android. Chrome OS, and anything that used it, is dead.
If a Firefox phone doesn't support native apps, it will be DOA.
Must be nice. I'm currently getting 2.61 Mbps.
There was just one little problem - they couldn't actually build one.