The issue isn't that this is bad per-se. It's that it's not very good. As the article points out, no one was really applying these regulations. Ultimately, this is grand standing more than anything else.
I'm always happy to see redundant legislation go away, but don't get grand delusions that this is Trump somehow removing burdens and making the government magically super efficient.
Your comment assumes that no one ever audits closed source implementations of encryption code.
You may well be right in the case of random implementations by random small shops (in fact, you probably are), but that really just tells you the well known trope "never implement your own cryptography".
In the case of the implementations built into {mac|i|tv|watch}OS, Windows, Android etc; for all that there are potentially bribable people writing those implementations, I'll take them any day over any open source implementation. In fact, the number of glaring, horrible security holes discovered (after attacks, not by code inspection) in OpenSSL recently has rather reinforced that.
The reason that most places don't have these check in hooks is simple - rule 1 in all good style guides is "if breaking the style guide in one off cases makes code substantially clearer, break the style guide."
Humans need to have the ability to say "no, in this one case it makes sense to do something odd to make this code readable".
If someone fucks up and puts a tab in the wrong place, or a space in the wrong place it's completely non-obvious to anyone until it's already in the repository.
In practice, it ends up with a code base that's got all kinds of weird indentation issues because people fuck up this way with great regularity.
Published source makes it a lot easier to spot problems with the code.
No it doesn't. It has been shown repeatedly that the idea that thousands of people will look at code and magically spot bugs is a myth.
In practice, people either 1) don't look at the code, or 2) don't have the domain knowledge to know what that very specific function is doing.
In reality, only the person who write it, and the 1 or 2 people who reviewed it really understand what's going on, and often not even the people who reviewed it.
Yep, I'd be willing to take a bet on what the actual causation here is.
Large tech companies employ a lot of people, and pay a lot of money. Most large tech companies use the WebKit style guide. The WebKit style guide says to use spaces, not tabs. Thus, most people who are getting paid big money are working at a shop that asks them to use spaces.
No, what it means is that the major tech companies that employ a lot of people, and pay a lot of money all have coding guidelines that say to use spaces.
I know for a fact the two very big ones use WebKit's style guide as a basis for most of their work, and that it asks you to use spaces.
If you're putting your own life in danger by driving a 10 year old clunker, that's fine. If you're putting customers into 10 year old clunkers, that's a problem.
Same with any other safety critical software. If you're putting customers (or taxpayers) lives in the hands of these systems, then you need to make sure you keep it up to date and secure.
Much more efficient would be to say, attach a block to the top of the CPU through which you pump some kind of coolant in the fridge's heat exchange loop.
Oh wait... that exists already, it's called water cooling.
To be fair, most water cooling systems don't use phase change to really cool super efficiently, but it's the same concept really.
Javascript is weakly, dynamically typed, since it allows the wrong type to be passed all over the place, and does runtime conversion with some unpredictable results Python is strongly, dynamically typed since it does not allow the wrong type to be passed around, but does that disallow step at runtime. Objective-C is weakly, statically typed since the compiler is the only thing that does type verification, but messages can be sent to pretty much any object of any type you like. Swift is strongly, statically typed since it does not allow the wrong type to be passed around, and does that disallow step at compile time.
Which means that you have no idea that you passed a dingus instead of a wackadoodle until some codepath that exercises the difference... and then you only find out at run-time, when your production system crashes. Sure, you can argue that this just means your automated tests were deficient, but that's always going to be the case, even when you apply great effort to get to 100% coverage. And you can argue that static typing isn't a perfect solution either, and I would never claim otherwise.
Hey, I never claimed it was good. I just corrected your assertion. Python *is* strongly typed. You absolutely can not pass a dingus instead of a wackadoodle. It will crash with a type error every time. It just will crash, instead of causing a compilation error, making the language strongly dynamically typed, not weakly typed as you asserted.
Nope, C++ is not a superset of C at all. There's lots of subtle little things that are different in very important ways.
Some examples:
1) void* is not considered implicitly castable to any other pointer type. That means that you need to cast the output of malloc for example.
2) character literals have the type char, rather than int. That means their size is different, and hence programs behave differently.
3) C++ does not require to use the keyword 'struct' in front of structure names. This can subtly change the behaviour of programs like int A; void foo(void) { struct A { char x; }; return sizeof(A); }, which will return the size of the variable A in C; and the size of the structure A in C++.
The two are very comparable. They're both dynamically typed interpreted languages that are commonly used for writing more complex scripts, and some basic things that might be called "applications". They both provide ease of programming, relatively human readable syntax, and both suffer from significant performance issues relative to more on-the-metal solutions.
Sure, but then, it's possible to find 4BR/2Bath homes for ~2.8k a month near Silicon Valley (say, Scott's Valley, Freemont, Dublin, Morgan Hill), and you'll get paid about 3k more a month than in the mid west.
The thing that matters when you do your sums is your total cash left at the end of the month, not how much rent/mortgage costs.
Slashdot Mirror
The issue isn't that this is bad per-se. It's that it's not very good. As the article points out, no one was really applying these regulations. Ultimately, this is grand standing more than anything else.
I'm always happy to see redundant legislation go away, but don't get grand delusions that this is Trump somehow removing burdens and making the government magically super efficient.
The two big ones of those fave though, are Apple and Google these days.
A WebKit... well... if you don't know what that is, you may need to learn a bit more about the tech industry.
Your comment assumes that no one ever audits closed source implementations of encryption code.
You may well be right in the case of random implementations by random small shops (in fact, you probably are), but that really just tells you the well known trope "never implement your own cryptography".
In the case of the implementations built into {mac|i|tv|watch}OS, Windows, Android etc; for all that there are potentially bribable people writing those implementations, I'll take them any day over any open source implementation. In fact, the number of glaring, horrible security holes discovered (after attacks, not by code inspection) in OpenSSL recently has rather reinforced that.
No, if that was the point, then the parent poster had no point.
The reason that most places don't have these check in hooks is simple - rule 1 in all good style guides is "if breaking the style guide in one off cases makes code substantially clearer, break the style guide."
Humans need to have the ability to say "no, in this one case it makes sense to do something odd to make this code readable".
It's not - the point is it's not worse either.
What's wrong is that errors are not transparent.
If someone fucks up and puts a tab in the wrong place, or a space in the wrong place it's completely non-obvious to anyone until it's already in the repository.
In practice, it ends up with a code base that's got all kinds of weird indentation issues because people fuck up this way with great regularity.
Published source makes it a lot easier to spot problems with the code.
No it doesn't. It has been shown repeatedly that the idea that thousands of people will look at code and magically spot bugs is a myth.
In practice, people either 1) don't look at the code, or 2) don't have the domain knowledge to know what that very specific function is doing.
In reality, only the person who write it, and the 1 or 2 people who reviewed it really understand what's going on, and often not even the people who reviewed it.
He's not on the council.
Yep, I'd be willing to take a bet on what the actual causation here is.
Large tech companies employ a lot of people, and pay a lot of money.
Most large tech companies use the WebKit style guide.
The WebKit style guide says to use spaces, not tabs.
Thus, most people who are getting paid big money are working at a shop that asks them to use spaces.
No, what it means is that the major tech companies that employ a lot of people, and pay a lot of money all have coding guidelines that say to use spaces.
I know for a fact the two very big ones use WebKit's style guide as a basis for most of their work, and that it asks you to use spaces.
Probably means tabs for indentation, spaces for alignment. They're still morons though.
If you're putting your own life in danger by driving a 10 year old clunker, that's fine. If you're putting customers into 10 year old clunkers, that's a problem.
Same with any other safety critical software. If you're putting customers (or taxpayers) lives in the hands of these systems, then you need to make sure you keep it up to date and secure.
So don't fucking run end of life software in safety critical situations...
Or in fact... at all.
Except that there's a shit ton of evidence in the case of Uber.
Much more efficient would be to say, attach a block to the top of the CPU through which you pump some kind of coolant in the fridge's heat exchange loop.
Oh wait... that exists already, it's called water cooling.
To be fair, most water cooling systems don't use phase change to really cool super efficiently, but it's the same concept really.
I mean, that is the definition of strong typing.
Javascript is weakly, dynamically typed, since it allows the wrong type to be passed all over the place, and does runtime conversion with some unpredictable results
Python is strongly, dynamically typed since it does not allow the wrong type to be passed around, but does that disallow step at runtime.
Objective-C is weakly, statically typed since the compiler is the only thing that does type verification, but messages can be sent to pretty much any object of any type you like.
Swift is strongly, statically typed since it does not allow the wrong type to be passed around, and does that disallow step at compile time.
Sure - in C++ there are better options. In C though, you don't have new available. It's completely normal for a C program to contain uses of malloc.
Heh, "as long as you don't do janky shit like the things you listed."
Yes... because using malloc is "janky shit".
Which means that you have no idea that you passed a dingus instead of a wackadoodle until some codepath that exercises the difference... and then you only find out at run-time, when your production system crashes. Sure, you can argue that this just means your automated tests were deficient, but that's always going to be the case, even when you apply great effort to get to 100% coverage. And you can argue that static typing isn't a perfect solution either, and I would never claim otherwise.
Hey, I never claimed it was good. I just corrected your assertion. Python *is* strongly typed. You absolutely can not pass a dingus instead of a wackadoodle. It will crash with a type error every time. It just will crash, instead of causing a compilation error, making the language strongly dynamically typed, not weakly typed as you asserted.
Nope, C++ is not a superset of C at all. There's lots of subtle little things that are different in very important ways.
Some examples:
1) void* is not considered implicitly castable to any other pointer type. That means that you need to cast the output of malloc for example.
2) character literals have the type char, rather than int. That means their size is different, and hence programs behave differently.
3) C++ does not require to use the keyword 'struct' in front of structure names. This can subtly change the behaviour of programs like int A; void foo(void) { struct A { char x; }; return sizeof(A); }, which will return the size of the variable A in C; and the size of the structure A in C++.
What Python doesn't have is strong type enforcement.
Actually, it does - Python is a strongly typed language, what it isn't, is statically typed.
The two are very comparable. They're both dynamically typed interpreted languages that are commonly used for writing more complex scripts, and some basic things that might be called "applications". They both provide ease of programming, relatively human readable syntax, and both suffer from significant performance issues relative to more on-the-metal solutions.
I'd say the comparison is spot on.
Sure, but then, it's possible to find 4BR/2Bath homes for ~2.8k a month near Silicon Valley (say, Scott's Valley, Freemont, Dublin, Morgan Hill), and you'll get paid about 3k more a month than in the mid west.
The thing that matters when you do your sums is your total cash left at the end of the month, not how much rent/mortgage costs.
No, you've had an elected prime minister for 0 years out of the last 10.
That's because in the UK the public doesn't elect the prime minister. They elect ministers, the ministers chose a prime minister amongst themselves.