...Out of college if they're decent they're ONLY in the top 6%* of income in the country...
Even though your statistic is not supposed to be real, it's conceptually incorrect and should be lower when you normalise it with initial investment.
Then you should also give it some context by considering initial investment in terms of time and effort - i don't think many would disagree that if you put in the effort then you are at least deserved of an equivalently better income and not just lucky or greedy.
Now take your normalised statistic with context and apply it to "that software developer in the US" who is being manipulated into lower pay... "Poor" would be an exaggeration, but "Cheated"... perhaps.
Given that in most systems allowed characters are number and letters with case sensitivity you only get this far:
alphanumeric:
36^2 = 1296
36^3 = 46656
so you only get 2
case sensitive alphanumeric:
62^2 = 3844
62^2 = 238328
also only 2
Not that it matters because like others say you would use this to do a brute force with a dictionary attack, this is still generally termed as brute force though.
Fantastic that they made these available for free and in such an accessible format.
Had a quick look through and one of the major differences between the HTML5 version and the book is the layout, everything is completely linearly presented... i suppose that makes it easier to support mobile devices and various sized screens etc, but not quite as nice as the book.
Depending on the re-use rights perhaps it could be given some love with @media queries and some more caring typography.
You wish you had always known "how to design a solution on my own time before I code a solution on company time"?
Why?
The more general principle is that you should design before you code... or rather: experiment, research, understand, test, analyse THEN design THEN code, then RE-write that code. It's the oppose to the write-once philosophy, if the task deserves it, then you should try to fully understand the problem before designing and coding for it.
But often with less engineering orientated programming you don't get time explicitly allocated for doing those things... so when you want to do a good job and are asked to write a moderately complex piece of software, you know that to save time overall and create a body of code that isn't going to cause you a headache to maintain later; you will have to invest some of your own time to think about it.
And the more cynical people here will say, "hey you don't get paid for that, programmers work too long hours blah blah blah" but you know what... it's worth it, because you become a better programmer, you learn more interesting things, you become better at thinking about problems and engineering solutions... if you aren't interested in those things then why are you coding at all, there are easier ways to make a living.
No they work fine... surprisingly a lot of the new css prefixed stuff has equivilent "-ms" prefixes. And i wouldn't have issue with those not working, using prefixed css properties comes with the knowledge that you cannot rely on them cross browser or even in the future.
What i have found is more of the same: browser quirks, things that are standards compliant and they claim to support fully but do not.
After spending a week of cross browser fixing almost entirely focused on IE11 deficiencies i can tell you first hand that it still sucks in more ways to list here and changing it's name will only create a new image to hate.
There is only one thing MS could do to make me happy with it's browser: and that is to discontinue it, because they have proven time and time again that they cannot improve it sufficiently.
Things like ABS EBS and the many engine control computers that i have probably never heard of do not need to be connected to the car stereo or the internet, they should be physically separate from any other non crucial set of components that they have no need to communicate with...
As Andrew Tenenbaum would put it:
When you flush the toilets on an airplane; an error in the toilet flushing mechanism should not be able to possibly cause missile launch systems to go off or engines to shut down.
The same applies for security of a system as important as breaking on a car: Any convenience given by connecting an ABS to a networked computer will never outweigh the safety benefit of the physically isolated security of not having it connected. It's too important and you don't need to have access to it on the same network as your frickin iTunes device. The same goes for all the other critical systems in a car. At most it's central hub should be separated from a networked hub that is capable of connecting to the internet.
In contrast, web development doesn't really require any of these. However, they all involve "programming", and the people writing the software can all be called "programmers", even if one's writing a website (no math) and another is doing a fluid dynamics simulation (lots of math).
I don't entirely disagree... but:P i am a web developer, who also happens to like lots of vector math, writing physics engines and in particular: writing SPH fluid dynamics simulations and other n-body simulations.
I would agree that some of my understanding of slightly above basic math is not necessary in most of the more common web development work in my job, but i do find it helps me be a better programmer in general... so perhaps the point is that math can make you a better programmer. Id also argue that it makes you better at engineering software rather than just "programming" it, but perhaps that has more to do with the experience of programming complex tasks that also require complex math.
That's why people with any sense know that "cutting down" is futile.
If you don't want lung cancer the answer is to not smoke... not just drop from 100 a day to 99 a day... if everyone saves 1% of their energy usage, it will add up globally to whopping... 1% reduction, in combination with the global population growth rate that is utterly pointless.
Change in energy production is the answer, and for that it's not quite as easy for everyone to "do their bit". Trying to justify quantity is impossible, because there is no line to draw, and ultimately not existing is the answer to solving the problem using quantity as the only variable.
:P It lacks certain subtleties of a proper midi keyboard such as velocity, but with 2-3 stacked octaves it's possible to play quite a lot. Learning a different arrangement isn't all that hard, it's just like playing a slightly different instrument. I actually find certain types of playing like monotone arpeggios easier with the supper light action laptop style keyboards, i guess it's also not that dissimilar to using a programmable midi pad.
My most fun tune to play this way yet has to be "The Halls of Science" by Mike Morasky (from portal), as a pure sine wave of course:D and what more appropriate way than performing on a computer keyboard.
Good advice, make pong then make something marginally more complex and repeat. Then when the OP knows enough he will probably have to re imagine his original concept anyway.
You have a more important problem than which language to chose. The most striking thing about your post is it sounds like you have grand designs for a game (your first game) and that's a bad thing. What you are doing is what almost every new game developer attempts to do... or at least thinks about: going in too big, running before you can walk, building a supersonic jet before you've built your first paper plane etc etc...
Sure you have programming experience and sound design and 3D modeling experience. But when you made your first 3D model did you create a masterpiece with immense detail? or just randomly poke around vertices of an abstract nurb? It's easy to get carried away having big plans for a big game, but you are one person, and you haven't? made your first game yet. You will fail in one way or another, so fail on something small first, then build up to your big idea (which will almost definitely change after you get your feet wet and get a sense of how practical the original ideas were).
Even just pick a small part of the big game that you envision... something so small that it should not take long to build (but it will take longer than you think), don't flesh it out, don't get carried away with detail, focus on a basic concept and see how far you get, this is how you learn: iterate. Wanting to have everything you imagine in your game is easy, deciding what you can have and what is more important is what you will learn.
Also something that might bias your choice of language, is that you will have to decide how much you want to build from scratch and how much 3rd party code you want to use, i.e in terms of engines. If you have very little interest in the physics engines and graphics engines behind games then you will have the task of choosing from the vast range of readily available ones. Not only does that sway your choice of language but it also sets you on a different path of learning, you have to learn how to use someone elses engine rather than learn how to write your own. Using someone else will give you more capability but less creative freedom and insight into how things really work, and could limit you to particular languages.
...The only difference I see between a traditional machine and this one is that the separation between transient state and persistent state is physical in a traditional machine - DRAM is transient, disk drives are persistent (and writes onto disk are commits to the persistent state), while this new machine would most likely enforce a logical separation...
The separation is not supposed to be that clean cut, otherwise the obvious solution is something like a dynamically sized swap file for system memory, or a harder physical allocation for contiguity, at which point the difference in operation would be small...
One of the biggest advantages (second to the physical performance improvement) of this concept is supposed to be the absence of unnecessarily duplicating persistent data into system memory, this is also mentioned in the article. This is what makes the logical separation far less clear, which is why i think the possibility for overlap and corruption of persistent data via running state is a reasonable concern.
"With persistent memory, the machine state gets messed up, you are so screwed."
Uh, have you looked into your computer recently? I believe you'll find either this little device called "an HDD" or this other little device called "an SSD". And people with those seldom get screwed.
If you read the article from the previous slashdot story about HP's "The Machine", you will find that they are not simply trying to use memsistors to replace main memory, but that they are also trying to consolidate the storage memory and working memory into a single piece of memory, this is why it is considered to be substantially different memory architecture which also requires the OS to work a little differently too... if you are old enough think "Ram Disk"
The difference being that usually any stored data to be used by the processor has to first be loaded into working memory from the large slow storage memory... as i'm sure you are aware, which is why SSDs are so popular... but even NAND is many times slower than SDRAM, so the separation remains.
The idea is that if a sufficiently fast, dense, persistent and cheap type of memory can be found then the best of both can be consolidated into one. The concern of the OP is that issues affecting running state could affect the traditionally less dynamic stored state... Working memory is usually treated as volatile and disposable, and your block device is not, but the line is now blurred.
I think it's a reasonable concern, but one that is likely to be addressed by the OS, a less physical separation between what is running state and what is not would need to be implemented, but at the same time the advantages of not "loading" data need to be retained... making everything that goes into the running state duplicate would bring back the "loading" problem slightly.
Anyone else find it odd that he used a distance squared force for a 2D problem? The surface of a circle depends linearly on the radius.
Linearly being the key word... take it one step at a time (before looking at what geometry inverse square law could represent). The rule is derived entirely from distance... Distance reduces the number of spacial dimensions into one, it doesn't matter how many spacial dimensions you have so long as you can find a scalar distance between two points.
For a less abstract explanation think of a 2D simulation as a geometrical subset of a 3D simulation (that subset doesn't have to be axis aligned), a 2D simulation could exist within a plane at any orientation in a 3D simulation...
So a 2D simulation will behave in the same way for distance based rules as a 3D simulation restricted to a plane would. what you do with that scalar distance is up to you (inverse square law just happens to describe lots of nice things like gravity and magnetism etc), there are also other rules that describe other forces based upon distance such as inter molecular forces (known as potentials in molecular dynamics). However all of these rules are compatible with both 2D and 3D simulation.
Slashdot Mirror
...Out of college if they're decent they're ONLY in the top 6%* of income in the country...
Even though your statistic is not supposed to be real, it's conceptually incorrect and should be lower when you normalise it with initial investment.
Then you should also give it some context by considering initial investment in terms of time and effort - i don't think many would disagree that if you put in the effort then you are at least deserved of an equivalently better income and not just lucky or greedy.
Now take your normalised statistic with context and apply it to "that software developer in the US" who is being manipulated into lower pay... "Poor" would be an exaggeration, but "Cheated"... perhaps.
Given that in most systems allowed characters are number and letters with case sensitivity you only get this far:
alphanumeric:
36^2 = 1296
36^3 = 46656
so you only get 2
case sensitive alphanumeric:
62^2 = 3844
62^2 = 238328 also only 2
Not that it matters because like others say you would use this to do a brute force with a dictionary attack, this is still generally termed as brute force though.
Fantastic that they made these available for free and in such an accessible format.
Had a quick look through and one of the major differences between the HTML5 version and the book is the layout, everything is completely linearly presented... i suppose that makes it easier to support mobile devices and various sized screens etc, but not quite as nice as the book.
Depending on the re-use rights perhaps it could be given some love with @media queries and some more caring typography.
You wish you had always known "how to design a solution on my own time before I code a solution on company time"? Why?
The more general principle is that you should design before you code... or rather: experiment, research, understand, test, analyse THEN design THEN code, then RE-write that code. It's the oppose to the write-once philosophy, if the task deserves it, then you should try to fully understand the problem before designing and coding for it.
But often with less engineering orientated programming you don't get time explicitly allocated for doing those things... so when you want to do a good job and are asked to write a moderately complex piece of software, you know that to save time overall and create a body of code that isn't going to cause you a headache to maintain later; you will have to invest some of your own time to think about it.
And the more cynical people here will say, "hey you don't get paid for that, programmers work too long hours blah blah blah" but you know what... it's worth it, because you become a better programmer, you learn more interesting things, you become better at thinking about problems and engineering solutions... if you aren't interested in those things then why are you coding at all, there are easier ways to make a living.
No they work fine... surprisingly a lot of the new css prefixed stuff has equivilent "-ms" prefixes. And i wouldn't have issue with those not working, using prefixed css properties comes with the knowledge that you cannot rely on them cross browser or even in the future.
What i have found is more of the same: browser quirks, things that are standards compliant and they claim to support fully but do not.
After spending a week of cross browser fixing almost entirely focused on IE11 deficiencies i can tell you first hand that it still sucks in more ways to list here and changing it's name will only create a new image to hate.
There is only one thing MS could do to make me happy with it's browser: and that is to discontinue it, because they have proven time and time again that they cannot improve it sufficiently.
for emacs
Things like ABS EBS and the many engine control computers that i have probably never heard of do not need to be connected to the car stereo or the internet, they should be physically separate from any other non crucial set of components that they have no need to communicate with...
As Andrew Tenenbaum would put it:
When you flush the toilets on an airplane; an error in the toilet flushing mechanism should not be able to possibly cause missile launch systems to go off or engines to shut down.
The same applies for security of a system as important as breaking on a car: Any convenience given by connecting an ABS to a networked computer will never outweigh the safety benefit of the physically isolated security of not having it connected. It's too important and you don't need to have access to it on the same network as your frickin iTunes device. The same goes for all the other critical systems in a car. At most it's central hub should be separated from a networked hub that is capable of connecting to the internet.
CSS + HTML + Javascript is how your HTML file used to look... (A big fucking mess).
Massive monolithic source files are not helpful. What is the purpose of this?
Also it doesn't seem like a long term solution. These helicopters would need to be carefully and sustainably fished.
If your food ends up with components of the paint in it that turn out to be mildly carcinogenic... there's this thing called the food chain.
There is also a problem with plastics entering the food chain in a similar way.
In contrast, web development doesn't really require any of these. However, they all involve "programming", and the people writing the software can all be called "programmers", even if one's writing a website (no math) and another is doing a fluid dynamics simulation (lots of math).
I don't entirely disagree... but :P i am a web developer, who also happens to like lots of vector math, writing physics engines and in particular: writing SPH fluid dynamics simulations and other n-body simulations.
I would agree that some of my understanding of slightly above basic math is not necessary in most of the more common web development work in my job, but i do find it helps me be a better programmer in general... so perhaps the point is that math can make you a better programmer. Id also argue that it makes you better at engineering software rather than just "programming" it, but perhaps that has more to do with the experience of programming complex tasks that also require complex math.
That's why people with any sense know that "cutting down" is futile.
If you don't want lung cancer the answer is to not smoke... not just drop from 100 a day to 99 a day... if everyone saves 1% of their energy usage, it will add up globally to whopping... 1% reduction, in combination with the global population growth rate that is utterly pointless.
Change in energy production is the answer, and for that it's not quite as easy for everyone to "do their bit". Trying to justify quantity is impossible, because there is no line to draw, and ultimately not existing is the answer to solving the problem using quantity as the only variable.
10 years older but also in the physical state equivalent to being in a coma for 10 years... I'd rather stay awake.
beat me to it :P
:P It lacks certain subtleties of a proper midi keyboard such as velocity, but with 2-3 stacked octaves it's possible to play quite a lot. Learning a different arrangement isn't all that hard, it's just like playing a slightly different instrument. I actually find certain types of playing like monotone arpeggios easier with the supper light action laptop style keyboards, i guess it's also not that dissimilar to using a programmable midi pad.
My most fun tune to play this way yet has to be "The Halls of Science" by Mike Morasky (from portal), as a pure sine wave of course :D and what more appropriate way than performing on a computer keyboard.
...this wouldn't be a story. The law did it's job and the man was fined, but there isn't a news article for every parking ticket.
The reason this is interesting is because the ethics of this part of the law are in question.
Just to clarify... by interaction do you mean the sum of forces?
If so; are the constituent forces well known, or can they be deduced from the known forces and the total interaction?
Good advice, make pong then make something marginally more complex and repeat. Then when the OP knows enough he will probably have to re imagine his original concept anyway.
You have a more important problem than which language to chose. The most striking thing about your post is it sounds like you have grand designs for a game (your first game) and that's a bad thing. What you are doing is what almost every new game developer attempts to do... or at least thinks about: going in too big, running before you can walk, building a supersonic jet before you've built your first paper plane etc etc...
Sure you have programming experience and sound design and 3D modeling experience. But when you made your first 3D model did you create a masterpiece with immense detail? or just randomly poke around vertices of an abstract nurb? It's easy to get carried away having big plans for a big game, but you are one person, and you haven't? made your first game yet. You will fail in one way or another, so fail on something small first, then build up to your big idea (which will almost definitely change after you get your feet wet and get a sense of how practical the original ideas were).
Even just pick a small part of the big game that you envision... something so small that it should not take long to build (but it will take longer than you think), don't flesh it out, don't get carried away with detail, focus on a basic concept and see how far you get, this is how you learn: iterate. Wanting to have everything you imagine in your game is easy, deciding what you can have and what is more important is what you will learn.
Also something that might bias your choice of language, is that you will have to decide how much you want to build from scratch and how much 3rd party code you want to use, i.e in terms of engines. If you have very little interest in the physics engines and graphics engines behind games then you will have the task of choosing from the vast range of readily available ones. Not only does that sway your choice of language but it also sets you on a different path of learning, you have to learn how to use someone elses engine rather than learn how to write your own. Using someone else will give you more capability but less creative freedom and insight into how things really work, and could limit you to particular languages.
...The only difference I see between a traditional machine and this one is that the separation between transient state and persistent state is physical in a traditional machine - DRAM is transient, disk drives are persistent (and writes onto disk are commits to the persistent state), while this new machine would most likely enforce a logical separation...
The separation is not supposed to be that clean cut, otherwise the obvious solution is something like a dynamically sized swap file for system memory, or a harder physical allocation for contiguity, at which point the difference in operation would be small...
One of the biggest advantages (second to the physical performance improvement) of this concept is supposed to be the absence of unnecessarily duplicating persistent data into system memory, this is also mentioned in the article. This is what makes the logical separation far less clear, which is why i think the possibility for overlap and corruption of persistent data via running state is a reasonable concern.
ok, then your interpretation of the OPs concern must be quite different from mine :S ... why the rhetorical HDD / SSD response?
"With persistent memory, the machine state gets messed up, you are so screwed."
Uh, have you looked into your computer recently? I believe you'll find either this little device called "an HDD" or this other little device called "an SSD". And people with those seldom get screwed.
If you read the article from the previous slashdot story about HP's "The Machine", you will find that they are not simply trying to use memsistors to replace main memory, but that they are also trying to consolidate the storage memory and working memory into a single piece of memory, this is why it is considered to be substantially different memory architecture which also requires the OS to work a little differently too... if you are old enough think "Ram Disk"
The difference being that usually any stored data to be used by the processor has to first be loaded into working memory from the large slow storage memory... as i'm sure you are aware, which is why SSDs are so popular... but even NAND is many times slower than SDRAM, so the separation remains.
The idea is that if a sufficiently fast, dense, persistent and cheap type of memory can be found then the best of both can be consolidated into one. The concern of the OP is that issues affecting running state could affect the traditionally less dynamic stored state... Working memory is usually treated as volatile and disposable, and your block device is not, but the line is now blurred.
I think it's a reasonable concern, but one that is likely to be addressed by the OS, a less physical separation between what is running state and what is not would need to be implemented, but at the same time the advantages of not "loading" data need to be retained... making everything that goes into the running state duplicate would bring back the "loading" problem slightly.
Anyone else find it odd that he used a distance squared force for a 2D problem? The surface of a circle depends linearly on the radius.
Linearly being the key word... take it one step at a time (before looking at what geometry inverse square law could represent). The rule is derived entirely from distance... Distance reduces the number of spacial dimensions into one, it doesn't matter how many spacial dimensions you have so long as you can find a scalar distance between two points.
For a less abstract explanation think of a 2D simulation as a geometrical subset of a 3D simulation (that subset doesn't have to be axis aligned), a 2D simulation could exist within a plane at any orientation in a 3D simulation...
So a 2D simulation will behave in the same way for distance based rules as a 3D simulation restricted to a plane would. what you do with that scalar distance is up to you (inverse square law just happens to describe lots of nice things like gravity and magnetism etc), there are also other rules that describe other forces based upon distance such as inter molecular forces (known as potentials in molecular dynamics). However all of these rules are compatible with both 2D and 3D simulation.
It's not pedantic there's a huge difference... take your ignorance and leave.