Neither will Matlab or Mathematica. If you don't know the mathematics behind whatever the hypothetical employer needs, knowing those languages is pointless. On the other hand, if you do understand the mathematics (e.g. finite differences, finite elements, etc.) but don't know Matlab or Mathematica, but instead know C++ or Python or Fortran, then picking up Matlab or Mathematica shouldn't be a problem. This is just another example of overly-specific job requrements.
when things are dark, and you need more light, it dims things.
Exactly the opposite: when things are dark, your pupils dilate and you need less light. Do you turn your smartphone brightness down in bright sunlight?
But brightness isn't the point -- color temperature is.
I haven't read the documentation; the software is too simple and easy for that, but the homepage describes what it does. Flux lowers the color temperature at night, which interferes less with sleep. I also find it much more pleasant.
It's nowhere near as hard as you're claiming. Those are bad practices even if you only ever intend to run on Windows. And.NET has had portable ways to do these things since version 1.0, and always encouraged their use.
The example above illustrates that; it is way more conventient to combine pathnames with such a non-portable string concatenation than it is with the right approach.
To me the correct, portable code looks easier to read and write. You don't have to check if directoryname already has a trailing seperator, for example. The Path APIs will also handle.. (and ~/ on linux).
In practice there are only a handful of things you need to know to write portable code in.NET. It was always designed to be cross-platform.
There is no interpreter --.NET code is never interpreted. The output of the C# compiler is CIL (Common Intermediate Language), which is akin to the output of the front end of the LLVM compilers (called IR "Intermediate Representation"). (note:.NET is older than LLVM)
In both.NET and LLVM, the intermediate language is not suitable for interpretation. It is always translated into native machine instructions before execution. In.NET that can either be at runtime (JITed) or install time (NGENed).
I'm simplifying of course. They don't need to write an interpreter, they need to write a back-end and port the runtime components.
Also, I don't think there's much if any C/C++ left in it, it's C# all the way down.
I totally agree. I've conducted dozens of interviews for software engineers. I couldn't hire a black developer if my life depended on it -- I've never had a black candidate. I know the recruiters aren't to blame -- they're desperate for qualified candidates. There were no black people in my university classes either. The dearth of women in IT gets plenty of headlines, but I've known lots of women programmers, including 3 bosses over the years. In my entire career, I've only ever known one black programmer.
Employer's have no incentive to care whether or not their employees are bored
That is just categorically wrong, in any industry. It's laughable in the software industry where getting and keeping employees is one of the biggest challenges.
You obviously don't work in the software industry. Employers not only tolerate all kinds of non productive things, they actively encourage them. Software engineers are treated like spoiled, geeky royalty.
The moment you, as an employee, start arguing that you should invest the employer's time in something that is less profitable but more interesting, you will be replaced.
OK, now I know you don't work in software engineering. Or any engineering. Trying to convince our employer to do things that are less profitable but more interesting is what we do.
I think it's a myth that people aren't learning C. I interview a lot of devs, many just out of college. Most of them know C/C++. They may be more comfortable with Java/C#/whatever, but they at least know C++ syntax and understand the memory model, etc. It would make no sense for universities to ignore C/C++, if for no other reason than the huge amount of code out there in those languages that you may need to understand. Kids in CS these days are still writing their own compilers, toy OSs and memory managers.
High level languages are more productive, no doubt about that, so it makes sense to learn them. But lower level knowledge is not made obsolete. You're still better off knowing C/C++ and some machine-level things, at least enough to read the code, understand a stack trace, memory dump, single step through compiled code, etc. So learning the high level tools is in addition to the traditional tools, not instead of them.
Yeah, I miss the days when we coders worked closer to the metal, calling getelementid directly instead of using some high level abstraction like jquery.
Anyone who thinks that programming is getting easier due to automation isn't a programmer.
I'll second that. I've been coding professionally for almost 20 years. Even done some assembly. Yes the tools are much better and more is automated, but the amount you need to know is only growing, and the expectations have never been higher. I don't think the automation is even keeping up actually. Making software is not getting easier.
our brains are not "like computers" in how they work
True enough, but that says nothing about what kinds of processing can be realized in either. There are so many layers of abstraction between the brain and the mind that it doesn't make sense to say that minds are made of neurons. Minds are made of abstract things which are made of abstract things, (which are... etc, etc), which are eventually made of neurons. But they could eventually be made of transistors, what does it matter how the bottom few layers work?
They're just playing the game that's being played, they all do it. For example: Apple's Tax Strategy
They'd be incompetent if they didn't. You can order your own tax sandwich here (pdf)
Oops, I guess I did imply that. I just meant that their are good reasons why the tax code is complicated, and that shouldn't prevent the taxation of intellectual property. The whole system needs massive reform anyway; companies that own a lot of IP already put them in holding companies and then licence them back to themselves.
Hmm.... Maybe they should do this with intellectual property.
The owner of intellectual property would be taxed based on a value the owner specifies annually. The government would have the option to purchase it for that amount, perhaps with an added premium. If the property is sold, the purchaser is taxed initially based on what they paid. Licences & royalties would be limited based on the taxed value.
I was about to say maybe this would be too complicated to get right... then I remembered our tax code.
Found a nice simple explanation of how this works here. There is a secret somewhere that isn't compromised, but it is ephemeral and isn't ever stored anywhere or transmitted. So that's what you meant by "long term". It's very clever. Makes perfect sense now, but it's counterintuitive, at least to me.
Anyway, thanks. I learned something new, which is why I still come to/.
even if all the long-term secrets (passwords, keys, etc.) involved in a conversation are stolen, the person who stole them cannot go back and decrypt the encrypted messages.
I can't wrap my head around that. The way you've described it, it isn't possible, unless the original intended recipient also can't decrypt it. There must be at least one secret somewhere that isn't compromised (the recipient's private key maybe).
BTW, does your sig ever get you modded redundant?:)
You're right. They usually aren't, but unintentional vulnerabilities can be subtle. Intentional vulnerabilities can be subtle to the point of genius. If you're just casually reviewing code that isn't specifically known to be vulnerable, and especially if the vulnerability is intentional, it may never be discovered.
This is why security sensitive functions need to be system code, not application code. System code, and hopefully coders, tend to get more scrutiny, have higher standards of quality, and have a more conservative approach in general. Repeating security functions in each application is insane.
How are you going to test a CPU? Unless you analyze the circuits physically, how are you going to do that it doesn't allow privileged instructions in unprivledged code e.g. when r14=6368696e65736520, r15=6261636b646f6f72?
I don't think that's (usually) true, but I'm no expert. My understanding is that latency is an issue because of excessive amounts of buffering in routers, because RAM is cheap and they can.
Exactly. The payload is encrypted, not the entire packet. You can't route traffic if you don't know where it's going. If people start watching Netflix through tunnels, the ISPs will just throttle tunnels.
Net neutrality doesn't have to mean that each packet is equally important, it should just mean that the ISPs and backbone network should be neutral about it. How about letting the endpoints decide how to prioritize their own traffic? Seems like an obvious way to stop abuse from ISPs and still get QoS for things that need it like games and video.
I don't get it. This makes absolutely no sense. A page full of apps each with their own implementation of encryption is not what we need. Why are we doing this at the application level? Have we all gone insane?
In the face of widespread Internet surveillance, we need a secure and practical means of talking to each other from our phones and computers.
Isn't that begging the question? I'm not a physicist, but my understanding is that the question of determinism is a matter of interpretation. (Quantum mechanics can be understood to be deterministic.) Isn't that the question they are poking at here?
Neither will Matlab or Mathematica. If you don't know the mathematics behind whatever the hypothetical employer needs, knowing those languages is pointless. On the other hand, if you do understand the mathematics (e.g. finite differences, finite elements, etc.) but don't know Matlab or Mathematica, but instead know C++ or Python or Fortran, then picking up Matlab or Mathematica shouldn't be a problem. This is just another example of overly-specific job requrements.
Most of the requirements you mention already apply to paying students. I don't think anyone is suggesting there be no requirements for free education.
...and eliminating environmental toxins, such as Perl.
when things are dark, and you need more light, it dims things.
Exactly the opposite: when things are dark, your pupils dilate and you need less light. Do you turn your smartphone brightness down in bright sunlight?
But brightness isn't the point -- color temperature is. I haven't read the documentation; the software is too simple and easy for that, but the homepage describes what it does. Flux lowers the color temperature at night, which interferes less with sleep. I also find it much more pleasant.
Probably Poe's Law, but you can never be sure.
Without a blatant display of humor, it is impossible to create a parody of extremism or fundamentalism that someone won't mistake for the real thing.
Disabling the security check is a bad idea though. It's just better to run all your malware in userspace. :)
You should not have to choose between using 3rd party hardware and having a secure system.
The example above illustrates that; it is way more conventient to combine pathnames with such a non-portable string concatenation than it is with the right approach.
To me the correct, portable code looks easier to read and write. You don't have to check if directoryname already has a trailing seperator, for example. The Path APIs will also handle .. (and ~/ on linux).
.NET. It was always designed to be cross-platform.
In practice there are only a handful of things you need to know to write portable code in
There is no interpreter -- .NET code is never interpreted. The output of the C# compiler is CIL (Common Intermediate Language), which is akin to the output of the front end of the LLVM compilers (called IR "Intermediate Representation"). (note: .NET is older than LLVM)
.NET and LLVM, the intermediate language is not suitable for interpretation. It is always translated into native machine instructions before execution. In .NET that can either be at runtime (JITed) or install time (NGENed).
In both
I'm simplifying of course. They don't need to write an interpreter, they need to write a back-end and port the runtime components.
Also, I don't think there's much if any C/C++ left in it, it's C# all the way down.
It really does not make any sense.
I totally agree. I've conducted dozens of interviews for software engineers. I couldn't hire a black developer if my life depended on it -- I've never had a black candidate. I know the recruiters aren't to blame -- they're desperate for qualified candidates. There were no black people in my university classes either. The dearth of women in IT gets plenty of headlines, but I've known lots of women programmers, including 3 bosses over the years. In my entire career, I've only ever known one black programmer.
It must start long before high school.
Employer's have no incentive to care whether or not their employees are bored
That is just categorically wrong, in any industry. It's laughable in the software industry where getting and keeping employees is one of the biggest challenges.
You obviously don't work in the software industry. Employers not only tolerate all kinds of non productive things, they actively encourage them. Software engineers are treated like spoiled, geeky royalty.
The moment you, as an employee, start arguing that you should invest the employer's time in something that is less profitable but more interesting, you will be replaced.
OK, now I know you don't work in software engineering. Or any engineering. Trying to convince our employer to do things that are less profitable but more interesting is what we do.
C is not going anywhere any time soon.
I think it's a myth that people aren't learning C. I interview a lot of devs, many just out of college. Most of them know C/C++. They may be more comfortable with Java/C#/whatever, but they at least know C++ syntax and understand the memory model, etc. It would make no sense for universities to ignore C/C++, if for no other reason than the huge amount of code out there in those languages that you may need to understand. Kids in CS these days are still writing their own compilers, toy OSs and memory managers.
High level languages are more productive, no doubt about that, so it makes sense to learn them. But lower level knowledge is not made obsolete. You're still better off knowing C/C++ and some machine-level things, at least enough to read the code, understand a stack trace, memory dump, single step through compiled code, etc. So learning the high level tools is in addition to the traditional tools, not instead of them.
Yeah, I miss the days when we coders worked closer to the metal, calling getelementid directly instead of using some high level abstraction like jquery.
Anyone who thinks that programming is getting easier due to automation isn't a programmer.
I'll second that. I've been coding professionally for almost 20 years. Even done some assembly. Yes the tools are much better and more is automated, but the amount you need to know is only growing, and the expectations have never been higher. I don't think the automation is even keeping up actually. Making software is not getting easier.
our brains are not "like computers" in how they work
True enough, but that says nothing about what kinds of processing can be realized in either. There are so many layers of abstraction between the brain and the mind that it doesn't make sense to say that minds are made of neurons. Minds are made of abstract things which are made of abstract things, (which are... etc, etc), which are eventually made of neurons. But they could eventually be made of transistors, what does it matter how the bottom few layers work?
They're just playing the game that's being played, they all do it. For example: Apple's Tax Strategy
They'd be incompetent if they didn't. You can order your own tax sandwich here (pdf)
Oops, I guess I did imply that. I just meant that their are good reasons why the tax code is complicated, and that shouldn't prevent the taxation of intellectual property. The whole system needs massive reform anyway; companies that own a lot of IP already put them in holding companies and then licence them back to themselves.
Hmm.... Maybe they should do this with intellectual property.
The owner of intellectual property would be taxed based on a value the owner specifies annually. The government would have the option to purchase it for that amount, perhaps with an added premium. If the property is sold, the purchaser is taxed initially based on what they paid. Licences & royalties would be limited based on the taxed value.
I was about to say maybe this would be too complicated to get right... then I remembered our tax code.
Found a nice simple explanation of how this works here. There is a secret somewhere that isn't compromised, but it is ephemeral and isn't ever stored anywhere or transmitted. So that's what you meant by "long term". It's very clever. Makes perfect sense now, but it's counterintuitive, at least to me.
/.
Anyway, thanks. I learned something new, which is why I still come to
even if all the long-term secrets (passwords, keys, etc.) involved in a conversation are stolen, the person who stole them cannot go back and decrypt the encrypted messages.
I can't wrap my head around that. The way you've described it, it isn't possible, unless the original intended recipient also can't decrypt it. There must be at least one secret somewhere that isn't compromised (the recipient's private key maybe).
:)
BTW, does your sig ever get you modded redundant?
You're right. They usually aren't, but unintentional vulnerabilities can be subtle. Intentional vulnerabilities can be subtle to the point of genius. If you're just casually reviewing code that isn't specifically known to be vulnerable, and especially if the vulnerability is intentional, it may never be discovered.
This is why security sensitive functions need to be system code, not application code. System code, and hopefully coders, tend to get more scrutiny, have higher standards of quality, and have a more conservative approach in general. Repeating security functions in each application is insane.
How are you going to test a CPU? Unless you analyze the circuits physically, how are you going to do that it doesn't allow privileged instructions in unprivledged code e.g. when r14=6368696e65736520, r15=6261636b646f6f72?
I don't think that's (usually) true, but I'm no expert. My understanding is that latency is an issue because of excessive amounts of buffering in routers, because RAM is cheap and they can.
Exactly. The payload is encrypted, not the entire packet. You can't route traffic if you don't know where it's going. If people start watching Netflix through tunnels, the ISPs will just throttle tunnels.
Net neutrality doesn't have to mean that each packet is equally important, it should just mean that the ISPs and backbone network should be neutral about it. How about letting the endpoints decide how to prioritize their own traffic? Seems like an obvious way to stop abuse from ISPs and still get QoS for things that need it like games and video.
In the face of widespread Internet surveillance, we need a secure and practical means of talking to each other from our phones and computers.
Agreed. I have a suggestion: internet layer encryption that hasn't been compromised by the NSA?
In Quantum Mechanics, determinism does not apply.
Isn't that begging the question? I'm not a physicist, but my understanding is that the question of determinism is a matter of interpretation. (Quantum mechanics can be understood to be deterministic.) Isn't that the question they are poking at here?