okaleniuk

I wrote Geometry for Programmers (https://www.manning.com/books/geometry-for-programmers) and even so, I don't think that math knowledge is really essential for programming. It is, of course, a non-perishable competitive advantage so from a career perspective, it makes sense to invest in mathematical education as early as possible. But it's not truly essential. Mathematical illiteracy does not disqualify a programmer from being a programmer.

In a modern technological climate, math savviness feels more like a superpower from the 50s comic books applied to a real-world profession. Would X-ray vision make you a better doctor? Probably. But nowadays, there are tomography machines in every hospital. Would flying make you a better urban planner? Maybe. But there are drones and satellite imagery. Would learning geometry make you a better game programmer? Sure. But there are engines and frameworks that do your math for you.

Surely, knowing geometry behind your tools enables you to outperform the "no math" solutions. Sometimes drastically. But today, it's more like a bonus not a necessity.

I do https://wordsandbuttons.online/ as a personal-ish website. I don't append my face to every page but a visitor is usually a few clicks away from my other works so the site is de-facto more or less personal.

First of all, it's a nice hobby. No bullshit programming, no frameworks, no dependencies, no annoying editors. I just write my code and text and enjoy doing so.

Second, it gives powerful motivation to study. I'm now writing a new page on rational interpolation and just yesterday I accidentally found a very simple way to avoid the Runge effect. I was just playing with interactives and it came out of the blue. There is no way I would have learned it otherwise.

Third, it helped me cement a publishing deal with Manning. They came to me and proposed to propose them a book on geometry. And so I did. The book is called Geometry for Programmers and it's coming this summer.

Fourth, I do public lectures (or at least I used to before the war), and the audience loves interactive illustrations. So I usually turn my site pages into presentation-like pages and do lectures with them.

So for me, having a website pays off in multiple ways.

I would go even further. People are not even that advanced stochastic parrots. In the similar task, we failed just as spectacularly as the GPT-4 did right now. Rust, Zig, Julia, Kotlin, and dozens smaller "new" languages fail to bear a smear of originality in them. Their authors remixed old ideas in different proportions and got different grammars as a result. That's something an LLM can do and much faster too.

But there is also Unison. That one new language that stands out, and the very fact that it does makes it improbable for an LLM to generate. LM is a language model, it avoids marginality and originality altogether by its design.

Language models can and are useful if you specifically want to avoid marginality. To reduce noise, to remove errors. There is huge potential in them. If the problem was to design the most average programming language with no purpose, no market niche, and no technological context - then GPT-4 is clearly a winner.

Tried that. It was fun. Didn't see any benefit though, went back to Python.

I don't care much about how the interface over LLVM looks like. As soon as I have the same result in the end, I'd rather stick to whatever has more users.

No one is a complete beginner I suppose. If you did some geometry in school, maybe some basic algebra, if you know what a function is (and I think every programmer knows what a function is) - you're good to go.

Even if the book is called Geometry for Programmers, I was trying really hard to make it self-sufficient. E. g. if you want to get deep into fascinating stuff like NURBS, you need to know a little calculus. So there is a chapter on calculus. It is shallow by itself but it opens the door for power series, polynomial interpolation, and then Bezier, rational Bezier, and finally NURBS.

Just like that, before introducing homogeneous coordinates and projective matrices, I put a chapter on linear equations. In any other geometry book it would have been completely redundant, but it explains so much about 4 point transformations, I just had to put it there.

TL&DR I sure hope so! This was my intention and if the book isn't appropriate for a beginner, I failed miserably as an author.

I should have used LaTeX from the start, yes. Manning accept manuscripts in LaTeX, moreover, they prefer to work with LaTeX formulas, and even if you write in MS Word, there is a pugin for LaTeX that they encourage you to use...

...and I learned all of that after the manuscript was done. That's on me, I should have been more inquisitive. Also, I should have asked about their style guide and technical requirements for the graphics. The book was supposed to be ready for printing sometime this month but now the launch is delayed till June since they have to redo 300+ graphics from scratch.

Self-publishing definitely gives you more freedom. But Manning also give you a development editor, a technical editor, a copy editor, a technical proofer, a copy proofer, plus a few dozen reviewers, and a whole production team. Writing for a publisher does feel like a deal with the devil, true, but it is not that bad of a deal.

If you want, write me a line (ok@wordsandbuttons.online) and we'll chat about publishing with Manning. Or without. My first book was published on Leanpub, and the second is available from wordsandbuttons.online directly.

Hello, OP here.

I wrote a whole book around the idea that mathematics is understanding first and symbolic computation second. In Geometry for Programmers, SymPy does the grind for you in every chapter (except chapter 2). Initially, I was even going to omit all the math notation altogether and turn all the formulas into Python snippets. But several reviewers said that this is too much, so now there are formulas you can see and snippets you can run.

https://www.manning.com/books/geometry-for-programmers

Well, you have to understand how Taylor series work anyway. And then, of course, you have to understand differentiation. SymPy doesn't rob you of mathematical knowledge it just automates the grind.

Of course, there is nothing wrong in doing symbolic computations by hand. But it's like walking vs. riding a bicycle. You're still getting from A to B but you save some time and energy with the machine.

That's true, Mathematica is more advanced. But it's not cheap and it brings in a whole new world with it. You do have to learn to use it explicitly while with SymPy, you can start after a 5 minute introduction. I would say, Mathematica a good professional instrument while SymPy is a good hobbyist tool.

A note to a bypassing reader, if you want to try Mathematica, and not sure if you would stay with it, don't go for a desktop license. Get a Raspberry Pi instead. Mathematica comes free for Raspberry!

Their principles are being reinvented today.

The idea of rejecting waste has been largely rejected itself in time of desktop dominance. Who cares if a desktop program runs 100x as slow as it should have if it 1) runs 2) is paid for anyway.

Now, in a cloud, YOU care if your program runs 100x as slow as it could have because you pay the AWS bill. All the waste is now your expense.

Plain JavaScript, plain HTML, very plain CSS. You can do the "view page source" in the browser and actually see the whole page source :-)

This way, I may be spending some extra time on reinventing the wheel. But I enjoy programming and this is a hobby project.

I read, I play, and then I write an interactive page about the thing. E. g. https://wordsandbuttons.online/complex_numbers_and_conformal...

I drifted away from Medium five years ago when I built by own site with interactive features Medium lacked. But I still continued publishing non-interactive pieces there. However, last March, when Facebook and Twitter started hunting down russian bots, Medium became the last safe haven for them. I blocked quite a few but eventually gave up and deleted the account along with a few dozen posts.

Yes, but you need to compute the matrix first. That's the tricky part I suppose since applying the transformation itself is as simple as multiplying every output bitmap center by the inverse projective transformation matrix and translating the original color.

I blame the desktop era. From the commercial standpoint, robustness is as good as reliability. And in the desktop paradigm, all the systems are robust enough because when something fails, there is always a user. A human part of the system that restarts the operation, or reinstalls the software, or, if nothing else works, buys an update (the best outcome for the software provider).

I had a similar problem a decade ago. Had a lot of paper bureaucracy in my life, didn't have a scanner on me at all times obviously. So I wrote an app that undoes the perspective: https://github.com/akalenuk/Docam

Pure JavaScript is fun and simple. If you want a hobby project, ditch all the frameworks, and go vanilla.

I started https://wordsandbuttons.online/ looking for something fun and meaningful to do. I wanted to practice interactive writing and wanted to involve the bare minimum of technology to go forward. So I use rudimentary HTML for layout, JavaScript for interactive illustrations and UI elements, and Python for massive code changes. I have a bit of CSS, but I don't use "cascading" feature of it so whenever I want to change a style overall, I write a Python script for that. On the plus side, every page is entirely self-contained, and my CSS is outrageously simple.

There are no dependencies not external no internal, so the workflow is entirely stress free. Well, rather stress isolated. If I break anything, I know that the breaking change is exactly in the thing I am currently working on and not anywhere else.

If you don't care about productivity and want to enjoy programming with as little tools and dependencies as possible, vanilla JavaScript is the way to go.

Sage is beautiful. And, as far as I understand, it is build on top of SymPy. But it brings in its own language. Nothing wrong with that though.

But what I love about pure SymPy is that it doesn't bring anything new to the language at all. You just write in Python, business as usual, it's just half of your variables are now computable symbols, and you can solve things symbolically whenever you want to.

Yes, exactly! A CAS lends you the skills of a mathematician once you already have the knowledge of a mathematician.

Computer Algebra Systems basically help you do math. If you want to integrate an expression, or solve a system symbolically, you can, of course, sit down and do that with pen and paper. Or you can "ask" a CAS to do this for you.

This is much easier than it sounds. And it's fun too: https://wordsandbuttons.online/sympy_makes_math_fun_again.ht...

I suppose, a lot of not games but game developers use CASes and we don't even know :-)

I think, there is one more topic a game developer should know about that fell through the cracks. It's computer algebra systems.

The rationale is simple. If you want to learn math fast, be prepared that you will stumble upon the lack of training as soon as you go from theory to applications. Normally, you need to go through a few books of exercises to start feeling comfortable with calculus or discrete math. And that's where computer algebra systems step in. They do your math for you.

It's much simpler to learn the basics of any CAS than to train yourself to solve all kinds of equations with pen and paper. It's easier (and more fun to be honest) to practice with a CAS and gain experience on the go too.

In my book, an introduction to SymPy takes only a few pages, but enables practicing with linear systems, matrix operations, calculus, polynomial approximation and interpolation, Bezier curves, NURBS, and polynomial transformations as the book progresses.

And SymPy is not even the most potent CAS out there. It is free and easily accessible though. If you know a little Python, you already know a little SymPy.

What do you think about https://www.manning.com/books/geometry-for-programmers ?

You can write in JavaScript without any frameworks and libs. The language itself is pretty self-sufficient.

5 years ago I started https://github.com/akalenuk/wordsandbuttons to focus on interactive writing. Just text and JavaScript to make interactive illustrations. There are no dependencies in principle. Nor external, neither external. Only text and code. Tons of fun, no red tape.

You might think that this works for small projects only. Well, there are more than 50 interactive pages now (would have been more, but I spent 1.5 years writing a book), and things haven't started to fall apart yet.

I strongly advice vanilla programming for hobby. JavaScript or not.

I just read Noise by Kahneman, Sibony, Sunstein, and I'm not sure that we should talk about politics at all anymore. We should think about politics, yes! Read about politics, listen about politics, and experience politics ourselves. But probably not talk too much.

Sharing opinions does reduce cognitive noise, but it also promotes and enforces cognitive bias. Which is a fair trade you might think, and in many practical domains it is. But under democratic system, we already have instruments to reduce noise. We have polls and elections. Democracy is well suited to mitigate cognitive noise.

But not bias. Imagine 100 people. 10 of them are experts in some particular field. The rest is completely clueless. Now let's hold a poll on some binary question from that field. Of 10 experts, let's say only 8 get the answer right because of the noise, let's call it a 20% noise. Of 90 non-experts, however since they all answer fully noisy anyway, roughly 45 will vote right statistically. The vote is the 53 vs 47 in favor of the right answer.

Now let's say, there is a bias that skews the result 10% towards the wrong call. In an expert community, this is not a big deal. 9 out of 10 experts will get the answer right. But among the general population, this would account for 9 votes in the wrong direction. The votes are now 45 vs 55, and the wrong decision is taken.

TL&DR Democracy is statistically more vulnerable to cognitive bias than to cognitive noise. And sharing opinions reduces noise but promotes bias.

Well, it's 21 century, nothing dies anymore but people. But you have to admit that it's not booming the way it deserves. I wrote in Erlang a decade ago and I thought that in ten years, surely, it will eat the world. Erlang got too many things right.

However, as people from other domains started employing its principles, Erlang's value diminished. E. g., if we now write supervisors in Python that run servers, event handlers and FSMs written in C++, and the system works fine, we don't really need Erlang.

Erlang is designed to accommodate principles for building reliable systems in the presence of software errors, and in such capacity it is definitely a worthy instrument. It is one of the few concurrency oriented programming languages in the world.

But as Joe Armstrong himself pointed out in his dissertation: "indeed concurrent programs can be written in languages which are not themselves concurrent". You can write concurrent programs in Python if you want. Or even shell. As soon as you can spawn a process and send it a message - you're good.

And this explains why Erlang hasn't conquered the world. As soon as it has established the principles, as soon as it proved them feasible in practice, it has made itself redundant. The lessons we learned from Erlang were larger than Erlang itself.

Counterexample. Numba is a Python compiler for heterogeneous computing. We adopted it last year and stopped rewriting code in C++ to run it on GPGPU.

On one hand, the conception from the 90s based on the most common Python implementation, on the other - a compiler that saves us tons of money. Which one adds value again?

Numba is a Python compiler for heterogeneous programming. It builds kernels with the same back-end NVCC does. With the equivalent AST, the kernel code it also equivalent.

We adopted it last year, and we don't rewrite code in C++ for GPGPU anymore. We save tons of effort on rewriting and even more on support.

How is this computer science?

Sorry, I didn't make it clear before. I'm winning. My credibility is well protected by our AWS bills.

Last year we adopted Numba for GPGPU programming. It is a Python compiler with LLVM back-end and full CUDA support. It generates the same code that NVCC (CUDA compiler for C++) does only it compiles Python code and not a C++ .cu dialect.

No one in our organization writes heterogeneous code in C++ anymore.

Also, Geometry for Programmers but only because I wrote it. I had to update my skills significantly while gathering material and doing all the experiments. Not sure if reading the book would have the same effect :-)