How exactly are FAX machines making your costs higher?
Probably because electronic form filling allows you to skip the steps of printing, handwriting, and then scanning each document, in addition to the dial and handshake, and the transmit time, and remember, time is money. Furthermore it reduces material waste and reduces the need for data entry and/or transcription.
And then of course, since fax machines involve moving parts and in most cases ink/toner, there's added time and cost involved in routine maintenance tasks.
Write paper in Kanji-capable word processor, or a JIT-kana-to-kanji processors (surprise, those highly industrialized Japanese folks actually solved that problem a long time ago). Then print, then fax fax. Or guess what, print directly to fax (you can do that in Windows, cool, I know!).
I really want to know if the people commenting in this tread have ever set foot in Japan. I wonder because there is a lot of BS being passed as opinions or technical observations on the subject.
At least the Japanese have an excuse. The kanji writing system made word processing systems more expensive and difficult to implement than in any other society. In our society, the fax machine hangs on in lines of business where documents have to be signed by hand. Though public key signing has been available for a generation, law evolves at tectonic speed.
I've been in Japan, and I've not seen any of these supposed impediments due to Kanji. They have software that handles that just fine. It has been a solved problem for quite a long f* time going all the way to mechanical typewriters and printing blocks.
It hurts the Japanese corporations who are trying to globally compete in outsourcing labor and driving down wages.
Bullshit. Japanese corporations (think Honda, SATO, Rakuten or Mitsubishi Heavy Industries) operate at a different level from the myriad of small companies that dot the Japanese eco-landscape. They use e-mail, they fax (and like anyone else, they can route those faxes into a digital format.) I do not see Honda having a hard time competing against VW, Kia or Ford, do we?
I've been in Japan, and the things that always amaze me are 1) the number of small businesses, 2) the very liberal zoning laws (you can pretty much open any business you want within a residential area, with some limits obviously), and 3) customer/provider loyalty.
Number 3 is very important, more than anything else. The whole Walmartization thing just doesn't happen in Japan. My mother-in-law in Kawasaki would buy her new Smart TV (a Toshiba IIRC) from a small mom-and-pop electronics shop in her neighborhood. She could well go to a large consumer electronics retail store like Yamada Denki to get the same stuff (perhaps even better and/or at better price), but she won't.
Japanese customers stick to the businesses they have been using - they stick to what they know has worked well for them (reliability -> loyalty) even if they have to pay more. And businesses go out of their way (perhaps too much in a cost-effective way) to ensure they retain their life-long customers' loyalty.
Case in point, every other year, my wife goes to this optics department to fix the frames of her reading glasses, which she bought from the store years ago. The store technicians do so, free of charge, no questions, ask. They fix the frames, don't charge anything, and genuinely bow and thank her, WITH SINCERITY, for coming to the store. Next reading glasses, she will buy them from them. She will wait a year or two till her next trip to Japan if necessary.
Loyalty goes both ways. And it serves them well in their economy. Japan is being afflicted by many things, an inflexible financial system, a convoluted small-business loan system, the lingering effects of their real state bubble, and population aging. But with all that, the purchasing power and quality of life enjoyed by the average Japanese worker or household has not been affected by the economic slum (only international expansion has, internal consumption and production remains the same.)
I'm sorry, but this "ZOMG analog" argument, I don't see how it negatively effects the still thriving small businesses in Japan. In Japan, they strive for quality, and they stick to what is known to work. Sometimes too much since that can have an ill effect on innovation, but it is hard to see "lack of innovation" and "Japan" in the same sentence.
What makes you think censorship is acceptable in Europe?
In Germany and France, you cannot parade with Nazi paraphernalia. That's one example of censorship that is legally impossible in the US (and I'll go on record to say, I wish we could have some of that type of censorship against people parading in white hoods... or people with pulled down pants or unattractive people wearing uber-tight spandex clothing 2 sizes too small.)
Collecting on them is another matter altogether. Especially in the event of a huge disaster which would trigger huge penalties. Would the provider pay you, or just file bankruptcy instead? Or just pay lawyers to keep the issue tied up in court for years?
that is why you go with large providers that have everything in place to settle should they fail to live up to their SLAs, not some SuggarDaddy one-man-shop cloud service.
There are idiots of every country that don't know where anything is. Ever ask an Asian where a country in S. America is ? They'll be doing well to understand you're not asking them about the USA.
It's such a foreigner douchebag strawman, but unfortunately most Americans don't know well enough to defend themselves from such FUD.
I'm sorry, but I've been in several countries and I know for a fact (as far as personal anecdotes go) that geographical knowledge is far worse here in the US than abroad, once you take education into a factor. Among uneducated people, obviously ignorance is rampant.
However, once you begin breaking people down into levels of education, things become more interesting. Even among educated people, "geo-politics" illiteracy is almost like a badge of honor. And it is not a manner of knowing the fine details of this orb - as a person could be excused to know what a country's current capital is, or what countries it shares borders with.
It is coarse grained things, like not knowing that Zimbabwe is in Africa, that Japanese don't speak Chinese, or, ffsk, that people from Guam or Puerto Rico are US citizens (you know, details from their own country!), how do we explain that!?!?!?
I find this to go hand in hand with this general antipathy towards education (and its many forms, from creationism to believing in homeopathy or that vaccines cause autism.) The general ethos in our country is that anything beyond rudimentary education is not only superfluous, but undesirable, and that recognition of education as a tool for economic advancement limits education to that which is immediately employable.
Reminds me of a friend of mine who used to check if a pointer was NULL, then if it was not and finally for other cases:
if(!p)
{...
}
else if(p)
{...
}
else
{...
}
His reasoning: the compiler could have a bug and this way you would catch that bug.
Holy mother of Baal. How would a reasonable compiler would had a bug on that???? I've seen compiler bugs (mostly on floating point arithmetic), A very, very, very rare type of thing. Someone who think there is a reasonable expectation that the compiler would fuck up something so basic, I would put that person in the same category as the "Jade Helm" conspiracy nuts!
Just use OCaml then, Go is nowhere near in speed and easy of use.
Yes, but it is not as ubiquitous, whereas Go already has a substantial number of job openings. I'm not doing this just for the sake of academic enlightenment (if I were, I'd be more inclined to go to Haskell.)
You have obviously no idea how the lower-level architectures of your computer operate.
On some platforms (eg. Intel), a single processor will have access to only a portion of the busses (eg. the PCIe bus and the memory). So anything that has access to specific hardware (say a GPU or a specific memory area) has to run on a specific processor (and that is done at a higher level by keeping it in the same thread). Sure you can go about it by doing an (automatic) memcpy every time you need to switch physical processor but that makes things more complicated and uses resources unnecessarily, especially if you cannot guarantee which processor your language will be using next.
There are certain things you can not abstract away in a lower-level programming language. If you as a programmer want to avoid 'seeing' that, you use Python (and even then, certain low level things are simpler implemented in C).
I actually do know how low-level architectures operate. The limitations that you describe imposes OpenGL to operates with a certain trade-off (lack of thread-safety), which incurs in a deficiency. A trade-off will always incur in a deficiency, however useful a trade-off is. If it weren't, then it wouldn't be a trade-off, but a perfect solution, like, I dunno, a unicorn that farts confetti while carrying cute bunnies into the sunset or something.
From Go's POV, its current computing model won't support non-thread-safe code (maybe never). That is also a trade-off (and thus a deficiency), but that it is model. And on that model, then it doesn't have to support OpenGL model.
It just fucking doesn't. That is not what it is for (just like Java computing model will never support direct pointers to memory.)
So what do you do in such situations when you want to integrate such disparate computing models? One word: shims. You create a shim. Let OpenGL run in its own real, and have the higher-level client side (in this case Go) communicate with it through that shim.
A hack? Fuck yeah, but welcome to the real world. You want to glue two different computing models together, guess what, you need a shim. I've actually have to do such things when having to integrated managed code (Java or.NET) with raw, native code or drivers.
Welcome to the world of trade-offs. Computing model A does not have to support computing model B just because the A-B shim is a PITA to develop.
guruevi wasn't talking to you; he's addressing the direct parent of his post, which is this claim by luis_a_espinal:
A deficiency that's not Go's problem to solve IMO.
In context, luis_a_espinal is making the dubious claim that Go doesn't need to support APIs which are not thread-safe, such as OpenGL.
It is not necessarily a dubious claim. We could take it as an architectural decision from Go. C computing model and semantics have no notion of non-nullable pointers. Or Java computing model has no notion of direct addressing. There is nothing peculiar then that Go's computing model does not provide out-of-the-box support for non-thread-safe code.
And whether non-thread-safety is required by low-level computing, that is irrelevant to the definition of a deficiency. Non-thread-safety is a deficiency, even if it is also a useful trade-off when programming at the low-level. All trade-offs, however useful they might be, involve deficiencies. If they didn't, then they would not be trade-offs, but perfect solutions.
A deficiency that's not Go's problem to solve IMO.
So you're saying that people should adopt Go only once all the major deficiencies in other common software systems have been addressed? That's going to be when hell freezes over.
(In addition, there are reasons for why OpenGL is the way it is; it's not a deficiency, it's a tradeoff.)
I didn't say that, but I'm not here to work over your deficiencies in reading comprehension. Therefore, I will let you assume I answered your question in the affirmative.
I'm still interested to hear what kind of answer might issue forth from Kernighan and/or Donovan.
A follow up question is, when I'm not constrained by high performance, I have been using Python 2-series. Does go offer something worthy of the effort to move to it there?
Speed and static typing. I do Python for a living (along Java and C/C++), and I dream of using a statically typed language that does some of the Python/Ruby syntatic magic. Go might be one way to do just that (read "might be", not necessarily "is" or "will be").
AC was referring to the fact you need to run all OpenGL code from same thread. Go's goroutines are not guaranteed to run on same thread (unless you do some black magic sorcerery).
A deficiency that's not Go's problem to solve IMO.
The problem in America is not the concept of standards, but their execution. The way we have them, they are a Rube Goldberg clusterfuck of a system, done like no one else on Earth. And for what? Supposedly to "fix" the lack of education in this country, compared to other countries such as Finland, Singapore, Japan or Germany.
Which is completely bollocks because the problem with education in this country is that we do not have a sensible way of funding public schools. We fund them primarily with property taxes. And obviously that creates a subsidized segregated system where people living in well-to-do zip codes (like me) get the best resources for their children, whereas people living in poor areas get to send their children to public schools that don't even have soap with which to wash their hands.
The problem is economic segregation, and what we see now are just symptoms that were going to happen, federal government or not. The only good thing I see about standardized tests is that they are the final catalysts that make all this crap come up to the surface.
If the federal government has a say on education, then the federal government must provide a fix % bracket for funding as a function of the number of children in a given school, regardless of zip code.
If we do not want the feds in it, but want the states to fund education, then do the same, have the federal government dictate a minimum % bracket for funding schools as a function of the # of children in them, regardless of zip code.
Either way will solve the root cause of all this crap. Then and only then we should be tackling test standardization.
Not everyone has the means to just get up and move to a different state and you're suggesting another star?
Agreed. What the OP said is the epitome of entitlement - expecting shit to be trivial because he simply states so (as part of whatever screwed up value system he holds dear.)
Whatever happened to having 10 to 20 years of general I.T. experience before entering InfoSec? A master degree is no better than a certification without the work experience.
Again, you have never heard about the degree. You do not even know the curriculum, and yet you question its validity? Information Assurance (IA) is more than IT security (just as security/enterprise security is more than just IT security.) Organizations and projects dealing with DOE and DOD contracts rely heavily in IA.
And why wait 10 to 20 years of general IT experience before entering InfoSec? Where did you get that from? If you, the generic you, pay close attention, you can get all you need in terms of experience within a decade? 20 years, then you have been doing something wrong.
God knows WTF Dijkstra meant to say with that saying, but the l33t hax0r echo chamber has been repeating that saying for years without even thinking what it means to the merits of said language or the malleability and adaptability of the human brain.
I've spent a long time reading through Dijkstra's works, trying to understand what he meant. I'm fairly confident my explanation is accurate.
Never heard of a master degree in Information Assurance.
We are all ignorant of something. That's ok. The important thing is not to be quick in jumping to conclusions without first checking our assumptions.
With that said, calling it an "East Coast" thing means what? You never knew about the degree, but you think you can call it names or something? Dude, expand your horizons. Ignorance is not bliss.
We hire "hackers" in the literal sense of the term - people who hack and slash with crude brute force to just "Git 'R Dun!" as fast and as cheap as we can
These are the people Edsgar Dijkstra was talking about when he said, "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Because BASIC is a hack-and-slash language. It takes a while to get out of that mindset.
I admire Dijkstra's wise words (in particular about this thought of software being usefully constructed.) With that said, that was a moronic thing to say (like, "never use goto".)
God knows WTF Dijkstra meant to say with that saying, but the l33t hax0r echo chamber has been repeating that saying for years without even thinking what it means to the merits of said language or the malleability and adaptability of the human brain.
Do not treat long ago spouted tongue-in-check remarks as axioms.
I wonder how many of these security flaw bugs would happen if we made companies actually legal responsible for the flaws in them?
This only makes sense when said software platforms that are 1) explicitly marketed for critical software development, and 2) client companies are, in good faith, using such platforms to build real critical systems.
Java is specifically marketed with a very clear disclaimer to not be used for critical systems. Same with, oh, I dunno, 99.99999 (and a whole bunch of other 9's)% of the rest of software built on this planet.
You would have to have a set of parameters by which bugs would be considered critical, in a manner agreed upon by a governing body that represents the majority of the software industry.
Software is not just a technical problem (certainly not one based off puritanical views of what software must do.) It is also an economic problem. Large bodies of software are far more complex than construction. And in construction, you can have flaws that would not cause a litigation against a construction company.
It is the reality of operating in an imperfect world with competing forces and limited resources.
In other words, shit happens. We fix it. We move on.
You need to prove a software bug is not just critical, but that is also bound by a kickass SLA that is agreed by seller and consumer (and which can be afforded by both, otherwise, shit never gets done, even if it is imperfect.)
Yeah. precompiled headers are great when you're working on a project in Visual Studio. But as soon as your large team goes off and creates a large complex build systems for a c++ project that compiles on multiple operating systems, it's really hard to continue using precompiled headers. Gcc has support for precompiled headers but it appears almost no one uses it.
C++ is supposed to have real module support one day. It was going to be in C++14 but it was delayed. Maybe that'll be nice. But knowing C++, it'll end up being a hugely complex beast.
This tells me your experience with C/C++ is rather shallow.
Same with Java and even Ruby - Null refs, running out of mem, not closing database connections, etc - things that also characteristics of unsafe code. I've done the lot of it, C, C++, Assembly, Java, Python, what have you. For e-commerce as well as low level stuff.
And I've seen unsafe code written in all of them. Treating pointers as ohhh-chupacabara! is just ridiculous. People who program with discipline avoid those problems, whether they program in C or Python or what have you.
Your worst developers will use uninitialized variables, pointers to previously freed memory, and overflow buffers. But not in Rust.
Don't worry. Your worst developers will find ways to create unsafe code in Rust in one way or another.
Slashdot Mirror
How exactly are FAX machines making your costs higher?
Probably because electronic form filling allows you to skip the steps of printing, handwriting, and then scanning each document, in addition to the dial and handshake, and the transmit time, and remember, time is money. Furthermore it reduces material waste and reduces the need for data entry and/or transcription.
And then of course, since fax machines involve moving parts and in most cases ink/toner, there's added time and cost involved in routine maintenance tasks.
Write paper in Kanji-capable word processor, or a JIT-kana-to-kanji processors (surprise, those highly industrialized Japanese folks actually solved that problem a long time ago). Then print, then fax fax. Or guess what, print directly to fax (you can do that in Windows, cool, I know!).
I really want to know if the people commenting in this tread have ever set foot in Japan. I wonder because there is a lot of BS being passed as opinions or technical observations on the subject.
At least the Japanese have an excuse. The kanji writing system made word processing systems more expensive and difficult to implement than in any other society. In our society, the fax machine hangs on in lines of business where documents have to be signed by hand. Though public key signing has been available for a generation, law evolves at tectonic speed.
I've been in Japan, and I've not seen any of these supposed impediments due to Kanji. They have software that handles that just fine. It has been a solved problem for quite a long f* time going all the way to mechanical typewriters and printing blocks.
It hurts the Japanese corporations who are trying to globally compete in outsourcing labor and driving down wages.
Bullshit. Japanese corporations (think Honda, SATO, Rakuten or Mitsubishi Heavy Industries) operate at a different level from the myriad of small companies that dot the Japanese eco-landscape. They use e-mail, they fax (and like anyone else, they can route those faxes into a digital format.) I do not see Honda having a hard time competing against VW, Kia or Ford, do we?
I've been in Japan, and the things that always amaze me are 1) the number of small businesses, 2) the very liberal zoning laws (you can pretty much open any business you want within a residential area, with some limits obviously), and 3) customer/provider loyalty.
Number 3 is very important, more than anything else. The whole Walmartization thing just doesn't happen in Japan. My mother-in-law in Kawasaki would buy her new Smart TV (a Toshiba IIRC) from a small mom-and-pop electronics shop in her neighborhood. She could well go to a large consumer electronics retail store like Yamada Denki to get the same stuff (perhaps even better and/or at better price), but she won't.
Japanese customers stick to the businesses they have been using - they stick to what they know has worked well for them (reliability -> loyalty) even if they have to pay more. And businesses go out of their way (perhaps too much in a cost-effective way) to ensure they retain their life-long customers' loyalty.
Case in point, every other year, my wife goes to this optics department to fix the frames of her reading glasses, which she bought from the store years ago. The store technicians do so, free of charge, no questions, ask. They fix the frames, don't charge anything, and genuinely bow and thank her, WITH SINCERITY, for coming to the store. Next reading glasses, she will buy them from them. She will wait a year or two till her next trip to Japan if necessary.
Loyalty goes both ways. And it serves them well in their economy. Japan is being afflicted by many things, an inflexible financial system, a convoluted small-business loan system, the lingering effects of their real state bubble, and population aging. But with all that, the purchasing power and quality of life enjoyed by the average Japanese worker or household has not been affected by the economic slum (only international expansion has, internal consumption and production remains the same.)
I'm sorry, but this "ZOMG analog" argument, I don't see how it negatively effects the still thriving small businesses in Japan. In Japan, they strive for quality, and they stick to what is known to work. Sometimes too much since that can have an ill effect on innovation, but it is hard to see "lack of innovation" and "Japan" in the same sentence.
What makes you think censorship is acceptable in Europe?
In Germany and France, you cannot parade with Nazi paraphernalia. That's one example of censorship that is legally impossible in the US (and I'll go on record to say, I wish we could have some of that type of censorship against people parading in white hoods... or people with pulled down pants or unattractive people wearing uber-tight spandex clothing 2 sizes too small.)
Collecting on them is another matter altogether. Especially in the event of a huge disaster which would trigger huge penalties. Would the provider pay you, or just file bankruptcy instead? Or just pay lawyers to keep the issue tied up in court for years?
that is why you go with large providers that have everything in place to settle should they fail to live up to their SLAs, not some SuggarDaddy one-man-shop cloud service.
There are idiots of every country that don't know where anything is. Ever ask an Asian where a country in S. America is ? They'll be doing well to understand you're not asking them about the USA.
It's such a foreigner douchebag strawman, but unfortunately most Americans don't know well enough to defend themselves from such FUD.
I'm sorry, but I've been in several countries and I know for a fact (as far as personal anecdotes go) that geographical knowledge is far worse here in the US than abroad, once you take education into a factor. Among uneducated people, obviously ignorance is rampant.
However, once you begin breaking people down into levels of education, things become more interesting. Even among educated people, "geo-politics" illiteracy is almost like a badge of honor. And it is not a manner of knowing the fine details of this orb - as a person could be excused to know what a country's current capital is, or what countries it shares borders with.
It is coarse grained things, like not knowing that Zimbabwe is in Africa, that Japanese don't speak Chinese, or, ffsk, that people from Guam or Puerto Rico are US citizens (you know, details from their own country!), how do we explain that!?!?!?
I find this to go hand in hand with this general antipathy towards education (and its many forms, from creationism to believing in homeopathy or that vaccines cause autism.) The general ethos in our country is that anything beyond rudimentary education is not only superfluous, but undesirable, and that recognition of education as a tool for economic advancement limits education to that which is immediately employable.
Reminds me of a friend of mine who used to check if a pointer was NULL, then if it was not and finally for other cases:
if(!p) { ...
}
else if(p)
{ ...
}
else
{ ...
}
His reasoning: the compiler could have a bug and this way you would catch that bug.
Holy mother of Baal. How would a reasonable compiler would had a bug on that???? I've seen compiler bugs (mostly on floating point arithmetic), A very, very, very rare type of thing. Someone who think there is a reasonable expectation that the compiler would fuck up something so basic, I would put that person in the same category as the "Jade Helm" conspiracy nuts!
Well, China and Zimbabwe are right next to each other, geographically. (Pretending to be an average American. How am I doing?)
Pretty close (and sadly, I'm not being sarcastic, there are people who wouldn't know one from the other.)
Just use OCaml then, Go is nowhere near in speed and easy of use.
Yes, but it is not as ubiquitous, whereas Go already has a substantial number of job openings. I'm not doing this just for the sake of academic enlightenment (if I were, I'd be more inclined to go to Haskell.)
You have obviously no idea how the lower-level architectures of your computer operate.
On some platforms (eg. Intel), a single processor will have access to only a portion of the busses (eg. the PCIe bus and the memory). So anything that has access to specific hardware (say a GPU or a specific memory area) has to run on a specific processor (and that is done at a higher level by keeping it in the same thread). Sure you can go about it by doing an (automatic) memcpy every time you need to switch physical processor but that makes things more complicated and uses resources unnecessarily, especially if you cannot guarantee which processor your language will be using next.
There are certain things you can not abstract away in a lower-level programming language. If you as a programmer want to avoid 'seeing' that, you use Python (and even then, certain low level things are simpler implemented in C).
I actually do know how low-level architectures operate. The limitations that you describe imposes OpenGL to operates with a certain trade-off (lack of thread-safety), which incurs in a deficiency. A trade-off will always incur in a deficiency, however useful a trade-off is. If it weren't, then it wouldn't be a trade-off, but a perfect solution, like, I dunno, a unicorn that farts confetti while carrying cute bunnies into the sunset or something.
From Go's POV, its current computing model won't support non-thread-safe code (maybe never). That is also a trade-off (and thus a deficiency), but that it is model. And on that model, then it doesn't have to support OpenGL model.
It just fucking doesn't. That is not what it is for (just like Java computing model will never support direct pointers to memory.)
So what do you do in such situations when you want to integrate such disparate computing models? One word: shims. You create a shim. Let OpenGL run in its own real, and have the higher-level client side (in this case Go) communicate with it through that shim.
A hack? Fuck yeah, but welcome to the real world. You want to glue two different computing models together, guess what, you need a shim. I've actually have to do such things when having to integrated managed code (Java or .NET) with raw, native code or drivers.
Welcome to the world of trade-offs. Computing model A does not have to support computing model B just because the A-B shim is a PITA to develop.
guruevi wasn't talking to you; he's addressing the direct parent of his post, which is this claim by luis_a_espinal:
A deficiency that's not Go's problem to solve IMO.
In context, luis_a_espinal is making the dubious claim that Go doesn't need to support APIs which are not thread-safe, such as OpenGL.
It is not necessarily a dubious claim. We could take it as an architectural decision from Go. C computing model and semantics have no notion of non-nullable pointers. Or Java computing model has no notion of direct addressing. There is nothing peculiar then that Go's computing model does not provide out-of-the-box support for non-thread-safe code.
And whether non-thread-safety is required by low-level computing, that is irrelevant to the definition of a deficiency. Non-thread-safety is a deficiency, even if it is also a useful trade-off when programming at the low-level. All trade-offs, however useful they might be, involve deficiencies. If they didn't, then they would not be trade-offs, but perfect solutions.
So you're saying that people should adopt Go only once all the major deficiencies in other common software systems have been addressed? That's going to be when hell freezes over.
(In addition, there are reasons for why OpenGL is the way it is; it's not a deficiency, it's a tradeoff.)
I didn't say that, but I'm not here to work over your deficiencies in reading comprehension. Therefore, I will let you assume I answered your question in the affirmative.
That was my impression.
I'm still interested to hear what kind of answer might issue forth from Kernighan and/or Donovan.
A follow up question is, when I'm not constrained by high performance, I have been using Python 2-series. Does go offer something worthy of the effort to move to it there?
Speed and static typing. I do Python for a living (along Java and C/C++), and I dream of using a statically typed language that does some of the Python/Ruby syntatic magic. Go might be one way to do just that (read "might be", not necessarily "is" or "will be").
AC was referring to the fact you need to run all OpenGL code from same thread. Go's goroutines are not guaranteed to run on same thread (unless you do some black magic sorcerery).
A deficiency that's not Go's problem to solve IMO.
Generally it takes a lot more time to study for the test than to take it.
Stop talking common sense. Why do you hate 'Murika!?
Standardized Tests Overwhelming Public Schools
The problem in America is not the concept of standards, but their execution. The way we have them, they are a Rube Goldberg clusterfuck of a system, done like no one else on Earth. And for what? Supposedly to "fix" the lack of education in this country, compared to other countries such as Finland, Singapore, Japan or Germany.
Which is completely bollocks because the problem with education in this country is that we do not have a sensible way of funding public schools. We fund them primarily with property taxes. And obviously that creates a subsidized segregated system where people living in well-to-do zip codes (like me) get the best resources for their children, whereas people living in poor areas get to send their children to public schools that don't even have soap with which to wash their hands.
The problem is economic segregation, and what we see now are just symptoms that were going to happen, federal government or not. The only good thing I see about standardized tests is that they are the final catalysts that make all this crap come up to the surface.
If the federal government has a say on education, then the federal government must provide a fix % bracket for funding as a function of the number of children in a given school, regardless of zip code.
If we do not want the feds in it, but want the states to fund education, then do the same, have the federal government dictate a minimum % bracket for funding schools as a function of the # of children in them, regardless of zip code.
Either way will solve the root cause of all this crap. Then and only then we should be tackling test standardization.
Not everyone has the means to just get up and move to a different state and you're suggesting another star?
Agreed. What the OP said is the epitome of entitlement - expecting shit to be trivial because he simply states so (as part of whatever screwed up value system he holds dear.)
Whatever happened to having 10 to 20 years of general I.T. experience before entering InfoSec? A master degree is no better than a certification without the work experience.
Again, you have never heard about the degree. You do not even know the curriculum, and yet you question its validity? Information Assurance (IA) is more than IT security (just as security/enterprise security is more than just IT security.) Organizations and projects dealing with DOE and DOD contracts rely heavily in IA.
And why wait 10 to 20 years of general IT experience before entering InfoSec? Where did you get that from? If you, the generic you, pay close attention, you can get all you need in terms of experience within a decade? 20 years, then you have been doing something wrong.
God knows WTF Dijkstra meant to say with that saying, but the l33t hax0r echo chamber has been repeating that saying for years without even thinking what it means to the merits of said language or the malleability and adaptability of the human brain.
I've spent a long time reading through Dijkstra's works, trying to understand what he meant. I'm fairly confident my explanation is accurate.
Accurate with respect to what? About what?
Never heard of a master degree in Information Assurance.
We are all ignorant of something. That's ok. The important thing is not to be quick in jumping to conclusions without first checking our assumptions.
With that said, calling it an "East Coast" thing means what? You never knew about the degree, but you think you can call it names or something? Dude, expand your horizons. Ignorance is not bliss.
We hire "hackers" in the literal sense of the term - people who hack and slash with crude brute force to just "Git 'R Dun!" as fast and as cheap as we can
These are the people Edsgar Dijkstra was talking about when he said, "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Because BASIC is a hack-and-slash language. It takes a while to get out of that mindset.
I admire Dijkstra's wise words (in particular about this thought of software being usefully constructed.) With that said, that was a moronic thing to say (like, "never use goto".)
God knows WTF Dijkstra meant to say with that saying, but the l33t hax0r echo chamber has been repeating that saying for years without even thinking what it means to the merits of said language or the malleability and adaptability of the human brain.
Do not treat long ago spouted tongue-in-check remarks as axioms.
I wonder how many of these security flaw bugs would happen if we made companies actually legal responsible for the flaws in them?
This only makes sense when said software platforms that are 1) explicitly marketed for critical software development, and 2) client companies are, in good faith, using such platforms to build real critical systems.
Java is specifically marketed with a very clear disclaimer to not be used for critical systems. Same with, oh, I dunno, 99.99999 (and a whole bunch of other 9's)% of the rest of software built on this planet.
You would have to have a set of parameters by which bugs would be considered critical, in a manner agreed upon by a governing body that represents the majority of the software industry.
Software is not just a technical problem (certainly not one based off puritanical views of what software must do.) It is also an economic problem. Large bodies of software are far more complex than construction. And in construction, you can have flaws that would not cause a litigation against a construction company.
It is the reality of operating in an imperfect world with competing forces and limited resources.
In other words, shit happens. We fix it. We move on.
You need to prove a software bug is not just critical, but that is also bound by a kickass SLA that is agreed by seller and consumer (and which can be afforded by both, otherwise, shit never gets done, even if it is imperfect.)
Yeah. precompiled headers are great when you're working on a project in Visual Studio. But as soon as your large team goes off and creates a large complex build systems for a c++ project that compiles on multiple operating systems, it's really hard to continue using precompiled headers. Gcc has support for precompiled headers but it appears almost no one uses it.
C++ is supposed to have real module support one day. It was going to be in C++14 but it was delayed. Maybe that'll be nice. But knowing C++, it'll end up being a hugely complex beast.
This tells me your experience with C/C++ is rather shallow.
It takes work to write safe code in C.
Same with Java and even Ruby - Null refs, running out of mem, not closing database connections, etc - things that also characteristics of unsafe code. I've done the lot of it, C, C++, Assembly, Java, Python, what have you. For e-commerce as well as low level stuff.
And I've seen unsafe code written in all of them. Treating pointers as ohhh-chupacabara! is just ridiculous. People who program with discipline avoid those problems, whether they program in C or Python or what have you.
Your worst developers will use uninitialized variables, pointers to previously freed memory, and overflow buffers. But not in Rust.
Don't worry. Your worst developers will find ways to create unsafe code in Rust in one way or another.
I much prefer cross-system languages.
You can't even write Swift cross-system. Even though you may be writing an app for a phone, you are forced to do your dev work on a Mac (unless you want to resort to stupid solutions like renting a machine that you can remote desktop in just to write code).
What you call a "stupid" solution is actually a pretty good alternative to buying a Mac when you want to do part-time iOS development.