okaleniuk

I misread it as edible PDF and thought wow! technology sure went a long way!

It would be nice to have an open standard for 3D food printing though.

I have some playable GUI too: https://wordsandbuttons.online/yet_another_floating_point_tu...

No. Doesn't agree with exploration.

I once had a job that didn't require any. I was given a specification and my job was to write some DSL-code of it. This would have been an excellent setup to practice TDD! Unfortunately, I wrote a script that basically translates the specification from word documents into DSL snippets and quit soon after.

"Best" is subjective. Some might argue that Assembly is the way to go: https://asm32.info/fossil/repo/asmbb/index

Personally, I had the most fun with Erlang and what happened to become N2O: https://github.com/synrc/n2o It is designed for speed not compromising reliability so it kind of looks like what you want.

Python+Django probably has better ecosystem though.

Indeed. But why git? I worked for 3 companies that adopted git for completely different reasons.

The first was open sourcing parts of their code so they just started using GitHub. Makes sense.

The second used to work with Subversion, and they stayed with it. The process was built around having one and only one server with all the CI, and the hooks, and the locks. Git was used with the SVN gate purely for developers' convenience. Makes sense.

The third one was on TFS, and they couldn't quite align their process with it. So they thought "our process is a mess so let's do git". This is a red flag. If you can't get your process straight with relatively simple tool, some more sophisticated tool will (and it did) only make it worse.

I think, the "source control question" comes from the Joel Test which is 19 years old. Almost every company uses source control now so it doesn't make as much sense.

A better question would be "why do you use [the source control they use]". The answer, if coming from a knowing person, may tell you quite a lot about how the technical decisions are taken in the company.

https://wordsandbuttons.online started as an experiment in unchitecture. Every page is a copy-paste of previous pages. On the plus side: no dependencies, every page is self-sufficient, and the code evolves freely from page to page.

On the downside, it's impossible to maintain it without automation. If I want to change something in several copies, I have to write a script to do this for me.

It's definitely not the best resource, but math intuition is what I'm promoting on https://wordsandbuttons.online/

I think, with modern tools, you need math intuition more than computational skills. That's why my site is all about interactive experience. There are no proofs or problems but a lot of things to tweak and drag.

Good for you!

I'm really glad to see that this no nonsense approach catches on.

Wow! That sounds fascinating.

Well, yes. GUI usually don't require much algorithmic work so there's just not much space to loose performance because of bad algorithms.

But I've seen researchers been vastly prolific in Python. They make segmentation or registration algorithms that beet the market, and then they call us (C++ engineers) to make them "fast". Usually we do, since we're trained for that. But it's never orders of magnitude. It's like 2-3 times faster.

And there were even cases where the C++ code appeared slower in the end. Well, we use slightly different math core than the numpy does and sometimes they're doing worse.

I actually thought about that. Not a framework but an ultra-efficient web-server. Going reductionist, a static serving web-server is just a key-value storage accessible via HTTP.

So I can run a Python script that gathers all the key-value pairs (names and pages), makes an optimized search tree out of them and spawns is out as an LLVM sheet of code. Then I only have to embed it into a trivial HTTP "answering machine", assemble it all under the target architecture as part of the deployment - and that's it.

I have more fun things to do right now, but my hosting contract expires in a year or so so I'd look for the alternatives by then.

Yes, that's all true.

Regarding the algorithms on small data, I even made a quiz about that: https://wordsandbuttons.online/challenge_your_performance_in...

Of course, Python or C++, if you want performance, you should design with performance in mind. Measurements and profiling are implied.

This is so true. You can maneuver within client expectations, and you certainly can optimize every particular features but marketing tools are often non-negotiable.

From the user's stand point - they are pure overhead, too. For my own project, I decided to ditch them completely. Including the analytics. Well, it would have been nice seeing all the nice plots but at the end of the day they just show vanity metrics. The real impact is immeasurable.

I have a rule of keeping every page on wordsandbuttons.online under 64KB. And no dependencies so, apart from occasional pictures from wikimedia, no other hidden costs for the visitor.

The number is of course arbitrary, but surprisingly it's usually quite enough for a short tutorial or an interactive explanation of something. And I don't even compress the code or the data. Every page source is human-readable.

So it is possible to have leaner Web. it just requires a little bit of effort.

Let's skip this and go right to web development in assembly:

https://board.asm32.info/

The author claims that it's only twice less productive to write in assembly than in high-level languages. But the performance gains are overwhelming so it might very well pay back the effort.

Yes, that's true.

There are clear and real incentives they are just more visible in the cloud where you pay for your hardware. Or in traditional workstation software where there's also market competition: "do that 10 times faster than the competitors and we'll talk".

It's true that with the Web the incentives are week. Sure, you'll lose some 10% of your potential visitors to frustration, but who cares if the traffic grows expectations are exponential.

It's really not about languages. Your code has to be perfect or trivial for the language to matter.

If it's easier for you to write better algorithms in Python than in C++, than your code will probably be faster while written in Python. Because better algorithms will easily get you further than 10x in terms of performance.

Writing code with performance in mind will get you there without any optimizations whatsoever. It's not about 12% speed up anymore, we're not living in the 70s. It's about not wasting orders of magnitude because of poor design choices.

I'm really glad that's becoming a part of public discourse.

Of course, poor performance is an ethical and economical issue. As the latter, we've been largely ignoring it in PC era (as a software guy, you don't pay for the hardware you're wasting so why should you care?) and now it's starting to be a concern with the cloud.

I would advise to put quite an effort into syntax highlighting, naming, and all the other things that will help an untrained eye to read the code.

If you don't know Lisp, it would be basically a pseudocode in prefix notation for you.

It takes some time to get used to reading s-expressions, but it's not that hard at all.

An excellent example!

Actually, it would be interesting to experiment with coloring all the abbreviations separately. P, then MUL, then H, then U, then W (or UW altogether). Not sure if it works, but it's something worth trying.

And both things are good news!

OCaml human-readable messages are brilliant! And machine-readable Clang output is very promising, too.

Language is something you can conduct a dialog in. In most of the computer languages you can't.

I'm not saying that C++ (or any other) is in any way inferior to Erlang because of human-readable error messages. But this property to communicate back and forth in the same language is definitely interesting.

Exactly!

Yes, indeed. Thank you!

I tried spacing it a bit just not, it does look better this way.

Thanks!

It starts with an idea. The whole thing: writing and interactive elements working together. Thinking it through with drafts and sketches takes a few weeks. Then I copy-paste a ./drafts/stub.html file, and copy-paste the elements that looks like what I'm trying to achieve the most there. Then I maul it into an actual code for the page. Then I write the text that has already been formed in my head, then I edit, and then I edit again, end the next morning I edit the last time. Then I put it into ./pages, fill in the index.html and the rss. Then I upload it to the hoster. That's it.

Some of these things can be automated. There's absolutely no need to deploy things manually. Unfortunately, the automateable things take the least amount of time. Sketching and editing take maybe 90% of it, and the programming takes the 90% of the remaining 10%.

Thanks!

It's simple, all the interactive plots are HTML canvases with a set of event handler assigned to them. I trigger init ialization functions right after the elements declarations, and they assign all the events: https://github.com/akalenuk/wordsandbuttons/blob/380c97f2535...

Almost every event changes the state somewhere and triggers the redrawing function: https://github.com/akalenuk/wordsandbuttons/blob/380c97f2535...

And that's all. It's a bit messy since it involves keeping state outside the functions, and it also requires a little boilerplate but it's manageable. Maybe if I would have hundreds of plots per page, this would have been a problem but for a blog-post size pages this works fine.