okaleniuk

It's definitely a step in the right direction. But wouldn't the next step be vanilla JS and any-script-managed HTML?

Some safety critical real time systems have strict time predictability requirements. This means that the whole loop should pass in exactly X microsecond, not more not less. For this, all the programming should be pretty much branchless.

For instance, all the sorting algorithm turn to, effectively, bubble sort since without branches, you always go with the worst case - and the sorting complexity is always the O(n^2). But it's okay, since the algorithm becomes predictable. You just swap a conditional swap:

    if a < b then swap(a, b)

with arithmetic swap:

    c = (a+b)/2
    d = |a-b|/2
    a = c + d 
    b = c - d

and that's it.

Engineers believe in definitions. By definition, philosophy is not a scientific discipline, because as soon as a discipline becomes scientific it... stops being philosophy.

As Alexander Pyatigorsky famously wrote, "the value of philosophy is in that nobody needs it".

Sure!

I'm not saying that philosophy is bad. Maybe making software just never meant to become an engineering discipline. I mean making clothes, laws, and music isn't. And it's fine.

But engineering does imply some rule-following.

It's sad that we demoted the field from engineering to philosophy. But it is what it is.

Next step - fashion and belief.

Our infrastructural team keeps about 2 MSLOC building on several compilers and running on several architectures. They report a new compiler bug every 2-3 years.

It's not about accounts, it's more about engagement. I still have my Facebook account, and I actually used it two years ago to fund my gym trainer and tell him I couldn't come.

Social media is a reality one can't simply ignore completely. One can complicatedly ignore it though to some level of success. For me, the minimal rules are: don't write on reddit, don't read on linkedin. Don't touch anything else. The orange site is ok-ish.

I use IDE at work but rarely at home.

My design is usually very simple, I don't have to keep a lot of things in mind to begin with. For instance, https://wordsandbuttons.online/ is about 100KSLOC now, but since it's inherently flat, no dependencies, no third parties, I can manage it with a Vim or a gedit with none of the IDE features. My implementation is always in the same file as the call.

I suppose, IDE makes writing harder code easier, which results in tons of saved time, but it also makes writing harder code easier, which results in tons of hard code.

I tried that in Geometry for Programmers https://www.manning.com/books/geometry-for-programmers

I needed a short chapter on calculus so I go on and explain Bezier curves and splines, but I couldn't afford a full introduction. So, I only explained how differentiation works and gave a few examples. The rest was delegated to SymPy.

Funny thing. There are errors in differentiation formulas in the final edition of the book. Some final edits went wrong or something. Anyway, so far, we had exactly 1 (one) complaint about that.

Apparently, programmers don't care about formulas if the code is already there.

I once wrote a game with no graphics or sound. It was a maze game: you were supposed to lead a mouse cursor through an invisible maze by touch. If you drive your cursor into a wall, it stops. You start at the bottom, and if you manage all the way to the top - you win.

Well, it's not completely useless. If you're extremely bored at work and don't want to draw attention, this could be your time waster of choice.

Yes but the amount of devotion is orthogonal to the language per se.

You can use Numba that uses the same LLVM clang does and write all the computation kernels yourself instead of using what Numpy provides. The only difference there would be JIT vs AOT compilation.

Or you can use Codon, that uses the same LLVM clang does and then there will be no difference at all.

Language is just an interface for a compiler.

We used to rewrite Python code in C++ "for performance". We stopped when the equivalent rewritten version appeared 3 times slower than the original.

The very notion of "fast and slow languages" is nonsense. A language is just an interface for a compiler, translator, or interpreter of some sort. A language is only steer wheel and pedals, not the whole car, so the whole arguments which one is faster is stupid.

In our case, AOT compilation backfired. We used (contractually had to) support older architectures and our Eigen built with meager SSE2 support couldn't possibly outrun Numpy built with AVX-512.

So we stopped rewriting. And then Numba (built on the same LLVM as clang) came up. And then not one but several AOT Python compilers. And now JIT compiler is in the standard Python.

Not entirely "hired", but my site helped me to land a writing job. I've been writing interactive pieces on https://wordsandbuttons.online/ since 2017, and in 2021 Manning asked me if I wanted to write https://www.manning.com/books/geometry-for-programmers and, well, two years after it went to print.

I would advice not to concentrate on coding per se. Coding fashion is volatile, today's good practice is a tomorrow's code smell. So instead of "programmer's books" I would suggest How Big Things are Done by Bent Flyvbjerg and Den Gardner. It's a new book (2023) and while it touches software engineering a bit, as the title suggest, it's more about getting big things done.

Around 2013, StackOverflow had started to turn into a history museum. There were still some niches where there was a bit of life but the rest become too much "do not touch the exhibits" to be viable.

Some more feedback. I don't understand what "Skills / Job Functions Importance" and "Industries Importance" are supposed to mean. What should that data impact?

If syntax mattered that much, CMake would have opted for SOME VARIABLE = SOME VALUE. But... they went for set(SOME_VARIABLE "SOME VALUE") instead. I don't know why.

Syntax-wise C is fine. I personally have a soft spot for Rebol's "syntax free" approach, but the world prefers C. Five out of ten TIOBE's most popular languages have C-like syntax.

And you're right that the perception of C comes from the usage of C. Of course it does. But this creates the vicious cycle, the cycle things like Pnut are trying to break.

And that's why I'm saying CMake should have been a library. We want the functionality of Make but not necessary the language. And Pnut shows us well that {language != functionality}.

For the sake of mental experiment, let's pretend Make is a separate executable, separate process, but with some sort of API. You can manage dynamic dependency graphs by calling its routines from C.

Now let's say Make is a dynamic library with all functionality exposed. You can invoke and manage subprocesses using its functions, but now your C program and the Make share a process together.

Now let's say Make is a C library. GNU Make is written in C so this is not impossible to imagine. Your C program shares the process, and the names on compilation+linking phase with Make, which is annoying. But you can still work with metadata using Make's facilities. Also now you can use all the tools: debuggers, profilers, static analyzers, dynamic analyzers - you use for the rest of your codebase.

We perceive C as a low-level language but, and Pnut shows it well, C is only a set of rules. We can write shell scripts with C rules. Why can't we then write build scripts?

I think you're confusing the language and the perception of language, the "rules of C" vs. the "brand of C".

What Pnut shows us is that the language itself is a very thin construct. C could be as low-level as you want, but it can also... compile to shell. Pnut shows that C is only a set of grammatical rules, and the source code in C doesn't necessary reflect the binary program, it's only a script for the C compiler. A compiler then decides how to interpret the source and what to do with it.

Now back to builds. The difference between:

    set(SOME_VARIABLE "SOME VALUE")

and

    set(SOME_VARIABLE, "SOME VALUE");

is purely grammatical. The underlying functionality is the same. When I'm saying, CMake could be a C library, I'm not saying we should ditch CMake and everything it brings to the table and start writing build scripts in pure C. I'm saying we can use both C language and CMake functionality with very little, skin deep, adjustments.

The only thing that keeps us down is the perception of C as a low-level language for low-level applications. C is for drivers and shell is for moving files around. And that's when Pnut comes up and tells us: "hold on, are they?"

With C, you have the whole toolbox and the toolbox factory.

I like how the terms of service and privacy policy are actually readable. Overall, the site design is really nice. However, I got stuck at "Your account is being set up, check back here later" so, feedback-wise, this is as far as I can go.

I love things like these because they shake our perception of normal loose. And who said our perception of normal doesn't deserve a good shake?

A C to shell compiler might seem impractical, but you know what is even more impractical? Having a separate language for a build system. And yet, here we are. Using Shell, Make or CMake to build a C program is only acceptable because is has always been so. It's a "perceived normality" in the C world.

There is no good reason, however, CMake isn't a C library. With build system being a library, we could write, read, and, most importantly, debug build scripts just like any other part of the buildable. We already have includeOS, why not includeMake?

Of course. Fun fact, the father of Galileo Galilei, Vincenzo Galilei was a musical theorist who, long before Bach, established the idea of equal temperament.

I myself don't believe in before/after thing. It's not that one day all the composers in the world agreed to write music by the book. I think things shifted slowly but steadily along with the technological progress. Compared to Galilei's time, in Bach's era there were more books to learn from, more and better developed instruments, and with the rise of bourgeoisie, more listeners (and musicians).

Bach is just a convenient milestone.

There is a point of view that all the western music is divided by Bach. The before era when music is mostly based on intuition and imitation, and the after era when music is strongly based on elementary theory. Bach himself, interestingly, belongs to the "before" era and as such is a pinnacle of intuitive pre-elementary music.

Just yesterday I found an album of Elizabethian remakes of Nick Drake's songs mixed with John Dowland's. The difference in composition is staggering. And Nick Drake was not a typical songwriter himself. Yet a 50 years old song is principally different from a 500 years old even when played by the same people on the same instruments.

I agree. But I'm not sure if there is the right audience for this thing to begin with.

I like minimalist stuff. I sometimes work on a pocket CHIP computer. My favorite phone is a Nokia 1280. One time I bought a Kindle Fire, was immediately disappointed and opted out for the classic black and white one right away. This device, however, is a fake and I saw that immediately through their landing page which is anything but minimalistic. It is annoying and distracting, and in terms of "effort you put" to "info you get" it is just horrible.

Now the comments have just proven my suspicion. The device is just an overpriced tablet. Not even e-Ink.

I wrote myself a debug tool at 2007. It's a piece of GUI "to borrow". A Windows app that catches Windows messages addressed to it and shows things in its own windows. It can show numbers you give it, give numbers back, count calls, and measure time. So it's a kind of debugger/profiler/GUI.

I open sourced it 8 years ago but it was not the original intention. I wrote it for myself. https://github.com/akalenuk/16counters

I wrote it in MASM32. It's therefore a tiny .exe file of about 7 KB. I spent maybe a few hours initially, but I've been adding features one-by-one for several years. I use it a few times a month.

Rotors. https://marctenbosch.com/quaternions/

Somehow, in less than 2 decades, people forgot that there was life before git. Before commit messages became compulsory, we used to write comments right in the code. And that was fine.

I can second the central thought: "The lesson you should draw is not that object-oriented is bad, but rather that whatever is the current trendy technique and trendy idea, is likely grossly overrated."

Because that's how we rate things. Not only in programming but generally. Social amplification is a thing that enables fashion industry and advertising in general. Businesses spend tons of resources on ads and media campaigns because they work. "Influencer" is not even a swear word anymore, it's a profession.

Do you really think that programming is somehow safe from the well known effect that affects every other sphere of life?

Neither.

"The lesson you should draw is not that object-oriented is bad, but rather that whatever is the current trendy technique and trendy idea, is likely grossly overrated."