Hacker Newsnew | past | comments | ask | show | jobs | submit | user8501's commentslogin

I personally believe that people just answer the question “do you visualize?” differently. I used to think I had “aphantasia” but like you said, you see it without seeing it. If your eyes and brain are functioning at all, your brain is perfectly capable of creating colorful images. Just look around. Those colors you see? That’s your brain.


No. There’s more to this. My wife has hyperphantasia. She can imagine an apple in front of my face, with her eyes open, and she will see occlusion.


It is absolutely not bait. Declarative programming for the web is certainly more pleasant, but direct DOM manipulation will always and forever have a performance upper hand over rendering frameworks that sit atop the DOM. Now this performance difference is usually negligible, but for projects like VSCode or this, there’s a very good reason they aren’t written using frameworks.


SQLite essentially achieves this as well by keeping the entire database in one file. It’s even faster than the filesystem in some cases: https://www.sqlite.org/fasterthanfs.html


Testes? Do you mean tests?


It’s Portuguese. It’s the same in the Lua codebase [1].

[1]: https://github.com/lua/lua


Thank you for informing me. I feel dumb for having chuckled.


don't feel dumb, your chuckle made me chuckle...


Aw crap! What are we gonna do now?


That’s a very good point. I feel, however, that the main idea is that bad philosophy is what ultimately fuels complexity.

The grug brain philosophy is simplicity at all costs, unless absolutely unavoidable.

The big brain philosophy as grug sees it is reusability at all costs, unless absolutely unavoidable.

The issue with this philosophy is that it tends to lock in first generation design choices and makes iteration more difficult.

It’s true that simplicity is difficult to find, but iteration is the key to finding simplicity.


> The issue with this philosophy is that it tends to lock in first generation design choices…

I agree.

A common approach to simple is “just start with the first thing that pops into your head and see how far you get.” I guess we could describe that as “simple to think of.”

A far less common approach to simple is “think through the whole problem, then remove everything that you don’t need.” This is what I’d call “a simple solution”, but note that it takes a lot more work to find it.


You've made one strawman accusation, and sure, people polarized that specific way (insisting only things worth doing are worth making reusable) are often doing bad things.

But I see plenty of anti-intectual anti-whatever attitudes founded in other forms of disdain. And I think grug reflects a broad/broader spectrum of negative biases.

One example, I've had an incredibly hard time getting folks to switch from dirty cobbled-together-with-StackOverflow shell scripts to Ansible, which is a just more sight-readable consistent experience. Or to zx or anything not just badly written shell scripts no one collaborates on.

People swear worse is better, are YAGNI (you ain't gonna need it) up the wazoo against 90% of everything. I think grug picks a lot of things to bash on, and a lot of devs do to.

I adore simplicity, but I find it challenging & long & arduous to hammer out of things. It's not fast to produce, or low thought. It's not made by resolutely sticking to lo-fi paths & mentalities.

We do need to be aware of the hazards at the other side, of ridiculous complexity & absurd/unnecessary systems engineering: yes! And I think grug offers some good almost-koans to reflect on, illuminates real hazards well. But I also think it's actively harmful & pernicious to put grug-brainedness on a pedestal, to go about actively disbelieving against any possibilities that might possibly be done simpler.

We seem to agree that simplicity takes iteration. Grug presents it as "oh I'm just dumb grug brain, I dunno" but in practice there is a lot of infighting in tech, and those who insist too loudly on aiming too high are not even IMHO as dangerous as those too loudly insisting on too low. We have to keep engaging possibility from all sides, & keep finding out what balances do work.


> One example, I've had an incredibly hard time getting folks to switch from dirty cobbled-together-with-StackOverflow shell scripts to Ansible, which is a just more sight-readable consistent experience.

Ansible can be used quite elegantly/simply, but the ecosystem as a whole is totally infested with "big brains" who insist on complicating things to make them more Reusable™.

There are really guys out there who will argue that your 20 line shell script actually needs to be two Ansible Roles each consisting of 10 files spread out among 2 layers of directories, and can be published to the Galaxy.

(In reality you can turn that 20 line shell script into a 30 line idempotent, single-file Ansible playbook, which is SOMETIMES worth it)


1. initialize all your variables - you will trip over this one, and it's always nasty

2. I typically throw a _ptr at then end for global pointers

3. use a unity build - create a build.c file and directly #include all .c files, and then just compile your build.c file. This will speed up compilation by many orders of magnitude, as well as allow the compiler to make better optimizations. Don't think too hard about how to separate your C files. I typically start in one file and I begin separating as themes or modules start to emerge. And even then, I wait a while, because I may change my mind. This allows my designs to become quite refined.

4. Make as few allocations as possible.

5. no comment

6. I get a personal kick out of sticking to C89, to my own detriment probably.

7. Errors are handled differently on a per function basis. But when an error requires a lot of cleanup, don't be afraid to use a GOTO.

8. Throw -fsanitize=undefined in there as well.


Initializing variables means the compiler will not be able to warn you when you use ununitialized value. I prefer to get the warning than use zero initialized one by accident.

Build.c file - good idea if performance is priority but you remove an option to get incremental builds (with make or the like).

I would add: read about warning options and enable as many as sensible ("-Wall -Wextra -pedantic from memory but there are a few others). Treat warnings seriously, don't allow them for longer than debugging/experimenting stage.

C99 has some useful features (like designated initializers or compound literals). Check if your compiler supports it.


There's nothing wrong with sticking to C89, but honestly, stdint.h is hard to pass up. That said, you can define your own sized integers using the stdint names in about a few dozen lines, since you don't really want to be using most of the stuff in the standard version.


oh, I love the idea of making a build.c!

Specially because I came across a compiler (sdcc) that doesn't support multiple source files (everything should be compiled individually and then linked with main.c


I think for many people, there’s an increasing feeling of dread that comes from using “modern” tools. There’s a heaviness to them that is difficult to put into words. And I think anyone who shares this sentiment feels joy when a tool feels light and airy and totally under their control.


If we didn’t reinvent the wheel we would all be riding on stone wheels.

Do people think we’re going to run out of space or something for these languages?

I’ll never understand how a persons personal triumph can be perceived negatively by another person.

Are you equally as upset when somebody paints a picture of a mountain, simply because other people have done that before?


Cool name


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: