Over 40,000 peoppe got to feel good while giving Boyan Slat $33 million and making him famous. A win for them and a win for him.
It's like donating at a dinner where Al Gore speaks about the environment. Donors feel good writing checks that cover the cost of the 200 gallons per hour of jet fuel burned in Gore's Lear jet to get him there. Donors feel good because he said "green" fourteen times, Gore gets to jet set around in a Lear jet. Win win.
Okay, I gave you the link, so when grow up you can read how Pascal is implementing string copy (in Pascal). "Intrinsic" in this respect just means it's included in the built-in library - it still has to be written, silly. The CPU. doesn't have a "copy a Pascal string" opcode, so someone has to write it. That would be guys like me.
You seem to have been too busy to read before replying. Let's try again:
-- the *implementation* of the string copy library function in C, using some conveniences including assignment returning the value. How would you write this "copy each character" in Pascal --
Are you familiar with the difference between IMPLEMENTING a function and CALLING it? You answered with how you would CALL the function.
Are you familiar with the difference between a character and a string? Just too much in a hurry to read "character by character"? If this isn't clear to you, you can see an actual implementation of Pascal string copy embedded here:
I learned Pascal 15 years ago. It's an okay language. At the time, Pascal was competing with Visual Basic. VB won.
The world could have chosen Pascal over VB, but they chose VB. In the 1970s, Pascal competed with C. The world chose C.
Now the industry is going through a phase in which people aren't distinguishing between beginner languages that are designed to be easy vs professional, enterprise-grade tools. Legos are easy, and I good way to learn some basics. You shouldn't build your house out of Legos. The same is true when building information systems. The simplest tools may not be the best things to build your enterprise with.
Watching my young daughter has taught me some things. Such as:
> And law of torts begat liability.
Two year olds very much understand "it's your fault and I'm mad at you", liability for harms done is not an invention of government.
What I thought was interesting is that two year olds will get really mad if another two year old copies their drawing (scribble) or song. Copyright seems to be instinctual.
> Yes, which is why it's important for the language to mitigate that as much as possible.
What's important very much depends on what software is being written. In a typical Excel macro, sure go ahead and check the domain of the value each time it is accessed. It'll be ten times as slow as not checking, but one shouldn't expect the project manager to manually check domains in his VBA. It's good and right for VBA to "mitigate it as much as possible".
In a graphics driver, speed is top priority. It would be a mistake to take ten times as long to execute to "mitigate as much as possible".
You certainly CAN write it in two lines instead of one, sure. You asked for an example of where it is convenient.
As I mentioned, here's the implementation of the string copy library function in C, using some conveniences including assignment returning the value. How would you write this "copy each character" in Pascal?:
while (*dest++ = *src++);
I'm going to guess that rather than one line, it'll be about fiveines. Some people prefer not to write five times as much code as needed.
Personally, I kinda like this habit to not only avoid the error but make it extremely obvious that I haven't done an assignment rather than a comparison:
if (4 == x)
By habitually putting the constant on the left side, I'd get a compile error if I accidentally typed = instead of ==.
There are many vulnerabilities in software in every language. As it happens, I maintain a database of every CVE ever issued, and part of my job each day is to look at any significant new vulnerabilities published that day. I've learned a couple things about languages and vulnerabilities. Obviously languages that nobody ever uses aren't used in vulnerable software very much - the number of vulnerabilities tracks fairly closely with how much use a language gets. Aside from that obvious fact, there is one more:
Languages designed to be easy for beginners tend to be used by beginners. Beginners make beginner mistakes.
There is very little stupid assembly code out there. There's a lot more stupid Python. This is simply because assembly is generally used by peoppe who know WTF they are doing; Python encourages people to make software without knowing what they are doing, which means they make really bad software.
Probably the worst language I've seen in terms of security was version 4 of PHP. It was really, really dumbed down and frequently used by people who had no clue - on public web sites. The creator of PHP openly and emphatically says he had no idea how to create a good program language, and he's right. He was trying to create a simple blog system, but inflated loops, variables, and conditions, so people started using it as a general purpose programming language for the web.
You DO have to be careful with C - and C programmers generally know that, and are careful. C is designed to be fast and to be flexible, and *simple* in terms of its built-ins, not to be a safe playground for newbies.
I fear the language which may be even worse for security than PHP 4 may be Rust. It may really surprise people for me to say that, but programs written in Rust may very well have more serious vulnerabilities than any other language. Why? Because Rust hypes some very basic features to a ridiculous degree, pretending that avoiding oob access magically makes your code secure, and many Rust programmers actually believe that. By far the vast majority of vulnerabilities are logic errors like "goto fail", not buffer overruns. No language can protect you against goto fail and similar oversights.
By making Rust programmers believe that just uaing Rust makes the software secure, or even meaningfully more likely to be secure, they are lulled into a false sense of security which encourages stupid mistakes. Have you ever seen a Rust program which even I the negative conditions in its unit tests? That's one of the most basic and important things you can do in terms of security. Many Rust fanbois truly believe that using Rust is magic, so they don't even test what happens when someone enters an invalid password, or an empty password, or how about SQL injection in the password? Rust doesn't normally buffer overflow, so no need to think about security, right?
> Why wouldn't function_that_uses_pointer() protect itself by doing the pointer check internally?
Because
for ( x=0; x++; x That way function_that_uses_pointer() wouldn't have to worry about someone remembering to do the check
If you want to hack together quick scripts without ever thinking about the possibility of either errors occuring, or some item simply not being present, perhaps VBA, Python, or Pascal is for you. C is for systems programmers who already need to be aware that they can't just make assumptions that every system and every situation will be just like the test they ran.
On a similar note, if something is marked deprecated long before it's removed, that matters. Five years of compiler/interpreter warnings saying "deprecated use of function in null context on line #47" gives plenty of opportunity. To fix it. From the bit of Python I've worked with, the recommended method on Friday completely stops working on Monday.
> C++ pre and post namespace breaks fstreams in programs, but compilers provide flags to override that, so it depends on what you mean by breaking. Does it count if the compiler by default breaks, but providing flags fixes it?
If it results in weird runtime errors, that's definitely a problem. If the compiler I'm using gives the message "incompatible use of fstream, try '-fstreamcompat' flag", that's no big deal.
Never mind Python 2 vs 3; one major reason I shy away from Python is the incompatibility in point releases. I'd see "requires Python 2.6â and see that I have Python 2.7 so it should be fine, right? Nope, code written for 2.6 won't run under Python 2.7. It needs to be EXACTLY 2.6.
It's at this point that some Python fanboi gets really upset and starts screaming about how that's now problem, with Python you set up separate virtual environments for each script, so that each one can have exactly the version of Python it is written for, with exactly the version of each library. When there is some bug or security issue you then hope that there is a patch for each, and deal with all that. (As opposed to every other peice of software in the world, which you simply upgrade to the latest version to get all the latest fixes). Yes, you CAN deal with that problem, it's possible, in most cases. You shouldn't have to. Every other language does some simple things to maintain backward compatibility in point releases (and mostly in major releases too).
Also the fact that most languages use every day and have used for decades use braces for blocks means my eyes and mind are very much trained for that. Braces aren't necessarily BETTER than just using indentation, but it's kinda like building a car which uses the pedals to steer and a hand stick for the gas. It's not necessarily inherently better or worse, but it would be almost undriveable for an experienced driver with decades of muscle memory in normal cars. Python's seemingly random choices on these things make it feel like using your feet to steer a car. There should be compelling reasons before you break long-established conventions and Python seems to prefer to break conventions just to be different. It seems the Python team is a bit like Berstein in that way. It's really annoying.
We're talking about people who suspect they may not actually be very good at their jobs, right? They feel like an imposter, as if the resume that got them hired included a lot. Of BS, right? If someone thinks their own resume is bull, maybe that's because they put BS on it?
In my experience, most people in tech actually did bullshit their resume and truly aren't very qualified for their job. Perhaps this is because often the people who interview them are managers, who don't have the technical skills they are looking for. It probably takes both a skilled technical person (or two) AND a manager to interview for some positions.
I may have made a mistake in my last round of applying and interviewing. Most people are nervous in interviews; I wasn't at all nervous because I had applied for a jobs that I was very well qualified for. Perhaps I should have stretched a bit more. My last two positions didn't involve much learning, I hit the ground running. Next time I might get significantly more money by stretching a bit higher, without bullshitting.
Prior to building out any fiber, Google announced what the goal was for the project. Their announced goal was to give the industry a kick in the pants so that more people would have better internet service in order to make use of Google services like YouTube and Google Docs. They never said they planned to make a bunch of money from the project directly. The success of the project should be measured against its goals.
Since Google's stated intent was spur other companies to get off their butts and make improvements, the fact that Google spent money trying to accomplish this doesn't make it a failure. The relevant questions are:
Did internet service improve in the areas that Google either deployed fiber or "threatened" to? (Yes) Did service improve in other geographic areas as part of an overall change spurred by Google fiber? (Data needed)
Google, aka YouTube aka Google Docs aka Android doesn't care too much whether the fast, reliable service you use for watching YouTube is wired or wireless. They only care about how much time you spend watching YouTube, as opposed to television or something else. If new wireless deployments mean people watch more YouTube, that's a win for Google. In fact, because Android is Google, they'd prefer wireless to wired.
Not that Google cares that much, but physics presents some very major hurdles for wireless to ever get any better than it already is in areas with up-to-date deployments. At usable frequencies, there is only so much bandwidth for everyone in the neighborhood to share. Higher bandwidth requires higher frequencies, higher frequencies don't go through walls.
It's looking very much like "wireless" is becoming more and more basically commercial wifi - the company rolls fiber past your house and the wireless portion is just the last few hundred feet. It's a fiber deployment wearing a mask of wireless.
$4,000 / would be sixteen times the size of the largest car companies in the world.
Here's the reality: Volkwagen revenue S$268 billion Toyota revenue $261 billion Daimler revenue $164 billion General Motors revenue $146 billion Toyota revenue $138 billion Telsa revenue $11 billion
Tesla would need to grow ten times larger just to become a significant car company (though still not in the top 5). If they are phenemonally successful, it will justify a stock price of $80.
> Remember the introduction of seat belts? Yeah, that had to be mandated
Seat belts were a highly advertised feature. Later, it was such a popular feature that gas stations sold them for installation in order cars, much like large stations sell aftermarket cupholders today. Here's a Chevron ad, only $5.95 for this great seatbelt:
After Ford was putting the belts I all of their cars, and after owners of older cars picked up the new-style seatbelt from the corner gas station, then the government said "oh yeah, that's a good idea. Let's mandate that."
Slashdot Mirror
The operator is syntactic sugar around a function call.
You can see the actual function in the source zip above.
Over 40,000 peoppe got to feel good while giving Boyan Slat $33 million and making him famous. A win for them and a win for him.
It's like donating at a dinner where Al Gore speaks about the environment. Donors feel good writing checks that cover the cost of the 200 gallons per hour of jet fuel burned in Gore's Lear jet to get him there. Donors feel good because he said "green" fourteen times, Gore gets to jet set around in a Lear jet. Win win.
We all know how to CALL a string copy function.
The discussion is how you would IMPLEMENT a simple function.
I put the implementation from Free Pascal in another post if you want to see it. It's about 15 lines.
Okay, I gave you the link, so when grow up you can read how Pascal is implementing string copy (in Pascal). "Intrinsic" in this respect just means it's included in the built-in library - it still has to be written, silly. The CPU. doesn't have a "copy a Pascal string" opcode, so someone has to write it. That would be guys like me.
The communication happens when you CALL strcpy. Inside of glibc, efficiency rules.
>> As I mentioned, here's the implementation of the string copy library function in C
> well one, it's better to use a library function like strcpy
Perhaps you didn't notice where I said that IS strcpy? You can't do this:
char * strcpy (const char * src, char * dest) {
return strcpy();
}
You seem to have been too busy to read before replying.
Let's try again:
--
the *implementation* of the string copy library function in C, using some conveniences including assignment returning the value. How would you write this "copy each character" in Pascal
--
Are you familiar with the difference between IMPLEMENTING a function and CALLING it? You answered with how you would CALL the function.
Are you familiar with the difference between a character and a string? Just too much in a hurry to read "character by character"? If this isn't clear to you, you can see an actual implementation of Pascal string copy embedded here:
ftp://ftp.freepascal.org/pub/f...
I learned Pascal 15 years ago. It's an okay language.
At the time, Pascal was competing with Visual Basic. VB won.
The world could have chosen Pascal over VB, but they chose VB. In the 1970s, Pascal competed with C. The world chose C.
Now the industry is going through a phase in which people aren't distinguishing between beginner languages that are designed to be easy vs professional, enterprise-grade tools. Legos are easy, and I good way to learn some basics. You shouldn't build your house out of Legos. The same is true when building information systems. The simplest tools may not be the best things to build your enterprise with.
That was entertaining, thanks.
Watching my young daughter has taught me some things. Such as:
> And law of torts begat liability.
Two year olds very much understand "it's your fault and I'm mad at you", liability for harms done is not an invention of government.
What I thought was interesting is that two year olds will get really mad if another two year old copies their drawing (scribble) or song. Copyright seems to be instinctual.
> Yes, which is why it's important for the language to mitigate that as much as possible.
What's important very much depends on what software is being written. In a typical Excel macro, sure go ahead and check the domain of the value each time it is accessed. It'll be ten times as slow as not checking, but one shouldn't expect the project manager to manually check domains in his VBA. It's good and right for VBA to "mitigate it as much as possible".
In a graphics driver, speed is top priority. It would be a mistake to take ten times as long to execute to "mitigate as much as possible".
Not everything is a shell script.
> Then you (clearly a C fanboi) writes code like this:
> while (*dest++ = *src++);
I actually didn't write the C library. I've written several Perl libraries; you'll find my code in Apache and Solaris, but Roland McGrath wrote glibc.
You certainly CAN write it in two lines instead of one, sure.
You asked for an example of where it is convenient.
As I mentioned, here's the implementation of the string copy library function in C, using some conveniences including assignment returning the value. How would you write this "copy each character" in Pascal?:
while (*dest++ = *src++);
I'm going to guess that rather than one line, it'll be about fiveines. Some people prefer not to write five times as much code as needed.
Personally, I kinda like this habit to not only avoid the error but make it extremely obvious that I haven't done an assignment rather than a comparison:
if (4 == x)
By habitually putting the constant on the left side, I'd get a compile error if I accidentally typed = instead of ==.
Slashdot ate the because. See:
https://developers.slashdot.or...
There are many vulnerabilities in software in every language.
As it happens, I maintain a database of every CVE ever issued, and part of my job each day is to look at any significant new vulnerabilities published that day. I've learned a couple things about languages and vulnerabilities. Obviously languages that nobody ever uses aren't used in vulnerable software very much - the number of vulnerabilities tracks fairly closely with how much use a language gets. Aside from that obvious fact, there is one more:
Languages designed to be easy for beginners tend to be used by beginners. Beginners make beginner mistakes.
There is very little stupid assembly code out there. There's a lot more stupid Python. This is simply because assembly is generally used by peoppe who know WTF they are doing; Python encourages people to make software without knowing what they are doing, which means they make really bad software.
Probably the worst language I've seen in terms of security was version 4 of PHP. It was really, really dumbed down and frequently used by people who had no clue - on public web sites. The creator of PHP openly and emphatically says he had no idea how to create a good program language, and he's right. He was trying to create a simple blog system, but inflated loops, variables, and conditions, so people started using it as a general purpose programming language for the web.
You DO have to be careful with C - and C programmers generally know that, and are careful. C is designed to be fast and to be flexible, and *simple* in terms of its built-ins, not to be a safe playground for newbies.
I fear the language which may be even worse for security than PHP 4 may be Rust. It may really surprise people for me to say that, but programs written in Rust may very well have more serious vulnerabilities than any other language. Why? Because Rust hypes some very basic features to a ridiculous degree, pretending that avoiding oob access magically makes your code secure, and many Rust programmers actually believe that. By far the vast majority of vulnerabilities are logic errors like "goto fail", not buffer overruns. No language can protect you against goto fail and similar oversights.
By making Rust programmers believe that just uaing Rust makes the software secure, or even meaningfully more likely to be secure, they are lulled into a false sense of security which encourages stupid mistakes. Have you ever seen a Rust program which even I the negative conditions in its unit tests? That's one of the most basic and important things you can do in terms of security. Many Rust fanbois truly believe that using Rust is magic, so they don't even test what happens when someone enters an invalid password, or an empty password, or how about SQL injection in the password? Rust doesn't normally buffer overflow, so no need to think about security, right?
Friggin Slashdot ate my post.
if ( thegamma = get_gamma() ) {
for ( y=0; y++; y < pixelheight ) {
for ( x=0; x++; x < pixelwidth ) {
do_gamma( x, y, thegamma );
}
}
}
It's kinda silly to check a million times that thegamma isn't null. Checking once is quite enough.
I know loops might be a little bit too advanced of a concept for some people, but advanced programmers use them once in a while. :)
Here's a fun function for you:
void strcpy(const char *src, char *dest) {
while (*dest++ = *src++)
;
}
Yep, that copies a string.
> Why wouldn't function_that_uses_pointer() protect itself by doing the pointer check internally?
Because
for ( x=0; x++; x That way function_that_uses_pointer() wouldn't have to worry about someone remembering to do the check
If you want to hack together quick scripts without ever thinking about the possibility of either errors occuring, or some item simply not being present, perhaps VBA, Python, or Pascal is for you. C is for systems programmers who already need to be aware that they can't just make assumptions that every system and every situation will be just like the test they ran.
On a similar note, if something is marked deprecated long before it's removed, that matters. Five years of compiler/interpreter warnings saying "deprecated use of function in null context on line #47" gives plenty of opportunity. To fix it. From the bit of Python I've worked with, the recommended method on Friday completely stops working on Monday.
> C++ pre and post namespace breaks fstreams in programs, but compilers provide flags to override that, so it depends on what you mean by breaking. Does it count if the compiler by default breaks, but providing flags fixes it?
If it results in weird runtime errors, that's definitely a problem.
If the compiler I'm using gives the message "incompatible use of fstream, try '-fstreamcompat' flag", that's no big deal.
Indisputable fact, eh? JPay ARE assholes, no doubt about that. We've they have these contracts with almost every state:
https://www.jpay.com/Pavail.as...
You'll notice the areas they do NOT have these contacts are places like Utah, Arkansas, and Alabama - mostly very Republican states.
Never mind Python 2 vs 3; one major reason I shy away from Python is the incompatibility in point releases. I'd see "requires Python 2.6â and see that I have Python 2.7 so it should be fine, right? Nope, code written for 2.6 won't run under Python 2.7. It needs to be EXACTLY 2.6.
It's at this point that some Python fanboi gets really upset and starts screaming about how that's now problem, with Python you set up separate virtual environments for each script, so that each one can have exactly the version of Python it is written for, with exactly the version of each library. When there is some bug or security issue you then hope that there is a patch for each, and deal with all that. (As opposed to every other peice of software in the world, which you simply upgrade to the latest version to get all the latest fixes). Yes, you CAN deal with that problem, it's possible, in most cases. You shouldn't have to. Every other language does some simple things to maintain backward compatibility in point releases (and mostly in major releases too).
Also the fact that most languages use every day and have used for decades use braces for blocks means my eyes and mind are very much trained for that. Braces aren't necessarily BETTER than just using indentation, but it's kinda like building a car which uses the pedals to steer and a hand stick for the gas. It's not necessarily inherently better or worse, but it would be almost undriveable for an experienced driver with decades of muscle memory in normal cars. Python's seemingly random choices on these things make it feel like using your feet to steer a car. There should be compelling reasons before you break long-established conventions and Python seems to prefer to break conventions just to be different. It seems the Python team is a bit like Berstein in that way. It's really annoying.
We're talking about people who suspect they may not actually be very good at their jobs, right? They feel like an imposter, as if the resume that got them hired included a lot. Of BS, right? If someone thinks their own resume is bull, maybe that's because they put BS on it?
In my experience, most people in tech actually did bullshit their resume and truly aren't very qualified for their job. Perhaps this is because often the people who interview them are managers, who don't have the technical skills they are looking for. It probably takes both a skilled technical person (or two) AND a manager to interview for some positions.
I may have made a mistake in my last round of applying and interviewing. Most people are nervous in interviews; I wasn't at all nervous because I had applied for a jobs that I was very well qualified for. Perhaps I should have stretched a bit more. My last two positions didn't involve much learning, I hit the ground running. Next time I might get significantly more money by stretching a bit higher, without bullshitting.
The second line that says Toyota should say Honda, I believe
Specifically:
1080p at standard frame rate is 8mbps.
That's 1MBps, so 10GB is 10,000 seconds.
10,000 seconds is 2.8 hours per month, at 1080p.
Prior to building out any fiber, Google announced what the goal was for the project. Their announced goal was to give the industry a kick in the pants so that more people would have better internet service in order to make use of Google services like YouTube and Google Docs. They never said they planned to make a bunch of money from the project directly. The success of the project should be measured against its goals.
Since Google's stated intent was spur other companies to get off their butts and make improvements, the fact that Google spent money trying to accomplish this doesn't make it a failure. The relevant questions are:
Did internet service improve in the areas that Google either deployed fiber or "threatened" to? (Yes)
Did service improve in other geographic areas as part of an overall change spurred by Google fiber? (Data needed)
Google, aka YouTube aka Google Docs aka Android doesn't care too much whether the fast, reliable service you use for watching YouTube is wired or wireless. They only care about how much time you spend watching YouTube, as opposed to television or something else. If new wireless deployments mean people watch more YouTube, that's a win for Google. In fact, because Android is Google, they'd prefer wireless to wired.
Not that Google cares that much, but physics presents some very major hurdles for wireless to ever get any better than it already is in areas with up-to-date deployments. At usable frequencies, there is only so much bandwidth for everyone in the neighborhood to share. Higher bandwidth requires higher frequencies, higher frequencies don't go through walls.
It's looking very much like "wireless" is becoming more and more basically commercial wifi - the company rolls fiber past your house and the wireless portion is just the last few hundred feet. It's a fiber deployment wearing a mask of wireless.
$4,000 / would be sixteen times the size of the largest car companies in the world.
Here's the reality:
Volkwagen revenue S$268 billion
Toyota revenue $261 billion
Daimler revenue $164 billion
General Motors revenue $146 billion
Toyota revenue $138 billion
Telsa revenue $11 billion
Tesla would need to grow ten times larger just to become a significant car company (though still not in the top 5). If they are phenemonally successful, it will justify a stock price of $80.
> Remember the introduction of seat belts? Yeah, that had to be mandated
Seat belts were a highly advertised feature. Later, it was such a popular feature that gas stations sold them for installation in order cars, much like large stations sell aftermarket cupholders today.
Here's a Chevron ad, only $5.95 for this great seatbelt:
https://www.thrillist.com/vice...
After Ford was putting the belts I all of their cars, and after owners of older cars picked up the new-style seatbelt from the corner gas station, then the government said "oh yeah, that's a good idea. Let's mandate that."