Many of the bold claims in this document are completely unsubstantiated.
Question 7: How does the Law regulate Blockchain and cryptocurrencies?
It can't. The principle argument that deals will be safe because the HTP residents are 'trusted and respectable companies' is naive and invalidates the fundamentally trustless model of blockchains.
Question 8: How is the mining activity of individuals regulated? Won't they launder funds through Belarus?
Money laundering happens every day with fiat currency, and with cryptocurrencies this is even easier. Exchanging currencies across both blockchains and boarders introduces innumerable difficulties for detection of money laundering.
The more blockchain regulation I see, the more I have to question the technical competence of regulators or the actual policy and implementation goals they have in mind.
Do they have technologists telling them, “yes we can track this.” Or do they not actually care about what they claim to, eg: money laundering...?
To write good programs that provide any useful functionality often a solid understanding of architecture and Mathematics is required. These skills are better understood in my opinion without focusing on software development as the end goal. A child is likely to be self motivated to write software if they have these skills and, most importantly, a desire to do so.
To write good programs that provide any useful functionality often a solid understanding of architecture and Mathematics is required.
Excuse me? Mathematics? I don't recall much of my K-12 math knowledge coming to play. You need to understand architecture to write simple programs that do useful things?
At risk of sounding like a passive-aggressive dickhead, is that what you think mathematics is?
Of course you don't think that, it was just me being a passive-aggressive dickhead, but putting aside me deserving a punch in the face, mathematics is about patterns and flow and repetition and singularities and mappings and transforms and logic and states and abstraction. Every program written is an expression of mathematical thought.
Kludging around with numbers is to mathematics what paint-by-numbers is to art.
Also, the way you describe mathematics can sometimes look like contemporary art (here, I think to Fluxus for example).
For me saying programming is tied to maths mostly is not a good thing: you'll be a better programmer if you studied linguistics, art, sociology and gender studies around your math classes.
Historically, programing has mostly been teached to science students but as we are currently talking about it, it will change maybe.
I can't speak to your K-12 math education, but I used mine all the time.
* There were always word problems. I had to take a few sentences or even a paragraph, and turn it into a representation that allowed me to get the answer. In later years this representation included variables that let me change some details and still get the right answer. Many of these had useless information included in the description, or were confusingly written, and I had to puzzle out the deeper model. This is not very different than taking a spec and making it into software. Particularly if you work directly with end users, who may include lots of unnecessary details. Sure the thing I build uses code rather than algebra equations, but that is not a huge leap - they are both mechanical rules that when applied to a problem give great, accurate answers.
* Speaking of variables - just learning variables and internalizing them is pretty damn useful for coding. This is not necessarily an easy thing to internalize - tutor some kids at basic algebra sometime. The idea that X holds a value seems pretty easy to grasp, but reasoning about X being any value[0] is pretty hard to grasp (until you do, then people say "i don't know why that was hard").
* Order of operations is another thing that was super important in k-12 math. Understanding that doing things in different orders gets different results is another big concept. It also leads to other operation ordering things - like doing things in a different order may be easier, and it's ok because they are equivalent (this is a huge chung of algorithms - do the steps in a different, equivalent order, and it's less work)
* Factoring in algebra and factoring in code are literally the same thing. Here is a list of variables and operations. Rearrange them into a different list of variables and operations using different functions.
* Substitution and systems of equations are pretty much the same thing. If y = x + 1, I can replace any Y with (x+1) and get correct answers. In coding we call this inlining and loop unrolling. Or even just replacing
$thing = func();
other_func($thing);
with
other_func(func())
And even more directly I was function composition (f(x), g(x), f(g(x)), f o g, etc) directly at least a couple times.
* Cartesian coordinates are very helpful when doing any kind of page layout - like say HTML/CSS.
* Simple set theory is useful all the time too. Heck I even use Venn diagrams (something I learned in 2nd grade) all the time. Set theory comes up obviously in databases (and other data stores) join is just a method of computing intersections. But it also comes up in other places when defining things. A huge problem when designing systems is what I call the "square/rectangle" problem - all squares are rectangles but not all rectangles are squares. This is fundamentally a set definition problem - figuring out what set we are talking about based on certain properties applies to (but is not limited to): database schema design, object hierarchy, program scope, filter creation, and so on.
Looking at your comment again makes me wonder if you are questioning the Parent's semantics of "useful functionality" and "simple" vs "trivial". I'm not going to dive into that, but I will say I used many of the above concepts daily in simple shell pipelines (opening the semantic argument of what a program is, but going as broad as possible, a shell pipeline is a one off program that can be turned into a stored program by putting it in a file).
I regularly want to find something in a logfile. Logs have a lot of data. Oh, I can find the subset with grep.
cat log | grep thing
Oh, thats a lot of data. I can need to filter more, I don't want all these lines about session validation. I guess I could make a regex. Or I could just factor that into a `grep thing|grep -v session`. Ill do that, its equivalent.
This is a trivial example of using composition, substitution and set thinking. I can extend it with "thats a useful search, maybe use a variable" and so on. Can this be learned, and done without having known the stuff taught in k-12 math? Maybe I don't know, but the place I first encountered and internalized those concepts is math class.
Even more controversial (from the is this a program point of view) is that these things are all useful in doing excel formulas and vba scripts.
[0] I know that's not strictly true, particularly with types in a computer language. But they taught me about domains, and things like "this is true when X is not 0" and so on. This translates well to code too - checking that values are acceptable in tests and input sanitization, or conversely, finding weird values by fuzzing are all applications of domains.
I think algebra actually hurts learning of programming, at least of the BASIC/FORTRAN/C style syntax. Programming variables don't work like algebra variables. I learned programming before algebra and had no problem with statements like "X=X+1". My brother on the other hand learned algebra before learning programming and a statement like that made no sense to him (what, 0 = 1?). Of course this was because in BASIC (as in many other languages) "=" is used both for assignment and comparison.
Programming and math could be learned together. Granted, math is not the only point of programming, but computation is actually how a lot of math is done. Also, within the confines of math, a program that does something useful (i.e., interesting) doesn't have to be a full-blown app with a GUI, so the programs can start out being much simpler. If the kids didn't become programmers, but came out more likely to use math in their lives, I'd still count it as a success.
I strongly disagree that there is any overall prerequisite relationship between the two fields. If you want to be a good writer, it's important to understand grammar, but telling children that they are not allowed to write at all until they've mastered a course in grammar is incredibly counterintuitive.
Learning needs to be holistic; you fill the gaps as you go.
Mathematical concepts are usually pretty intuitive. I think that the problem is more the notation that we teach than math itself being unintuitive and difficult.
I'd also say that programming is a mathematical endeavor by nature; logical manipulation is a branch of mathematics. If you're working at a level of abstraction where you aren't specifying logical manipulations, then you're filling out a template, not what I'd call "programming".
If all you're writing are CRUD apps then maybe you won't need it, but try doing graphics programming without mathematics. Which will be most interesting for children?
I learned basic trigonometry early (with a textbook and some advice from a school mathematics teacher) for the purpose of rotating vector graphics in BASIC to make a Spacewar clone. I expect there are many people who learned about complex numbers because they wanted to draw fractals. And linear algebra can sound boring until you realize how useful transformation matrices are in graphics programming. Programming is a great motivation for learning mathematics because it's so much more fun when you have mathematics skills.
To provide useful functionality in the end, you need a set of requirements produced by someone who understands the big picture: how the intended program fits into the world and solves a problem.
