HN user

bartq

233 karma
Posts11
Comments82
View on HN

Actually... I use my own keybindings which are more ergonomic twist of Emacs bindings. For example for moving char left I use C-d and to move word left I use C-S-d (control+shift+d). Convenient to press using both hands (using right shift with pinky). Of course Control is swapped with Caps lock.

Friend... don't try to "switch". Just use multiple tools at the same time. I personally use all: Neovim (great writing/editing experimence, LSP+Treesitter+fzf allow you to get really far), Emacs (for Magit), VS Code (if Neovim or Emacs breaks I can still edit the code ;)) and WebStorm to run tests using nice and rich UI. Don't try to limit yourself artficially.

If your goal was to release some library with a website - you made it, congrats. Looks really nice to my eyes.

However, as a developer, I want to see something else:

1. Example projects created with this library. Challenges, solutions, pains, wins.

2. Video demonstrating how you created simple app with your lib. Reading docs is a too high bar in very crowded JS ecosystem. For example I want to see:

  - how tooling works, 
  - how debugging works, 
  - how build process works.
  - anything else this tool is strong with.
If your goal was to create this library - then, again - you made it. But what next? Best libraries or frameworks are created during work on some real project and they are extracted from the target creation.

One more thing about iPad: I think it has the best on the market form factor, see pictures how magic keyboard elevates the iPad device which makes it's floating in the air a bit. I want to have the same for other laptops, because when you type on normal laptop in LAPTOP position, your fingers stand in your eyesight covering bottom part of the screen which is atrocious. AND: computer is in the screen which makes keyboard always cool. The same as in Surface Pro.

Until recently I owned both MacBook Pro 16 M1 Max and iPad Pro 12.9 with magic keyboard. I love MacBook Pro 16 for work either on desk with connected big display or on laptop stand. Occasionally I use it as a notebook flat on the desk, but don't really like it long term, it forces you to look down which is not comfortable. But I HATE MBP16 to use as a LAPtop, it's too big, I can stand it maybe for 30min, max 1h.

So here comes iPad Pro 12.9 - lightweight (maybe not that light including Magic Keyboard), but it's great to use in laptop way, on chair, in bed etc. Great to browse web, scroll through videos and write notes or emails. I liked this form factor so much that I started to figure out how to make it a coding machine. That's problematic of course, so I ended up buying paid terminal App in App Store to connect over ssh/mosh to some server/other machine and use terminal with tmux/nvim etc. Installed nerdfonds, started using TUIs and it was working pretty well. But, I hate terminals for long term real work. I want to use heavy UI debuggers, click around/browse, move etc, my work is not only inserting text. I considered buying Asus Zenbook s13 OLED and install Linux on it to have two devices to use depending on my mood and physical position I wanna have. But, first, Zenbook is on Intel/Ryzen which means heat and fan noise, two, there are high risks my linux setup will require tweaks and care which I'm not interested in.

In summary: I bought base MacBook Air 13 M2 and use it as couch/cafe machine as alternative to MPB 16. So I have 3 Apple devices. Which is... fine?

The obvious solution is to use nor ORMs or raw SQL generated with various helpers in your language, but to open up DB engine to execute low level bytecode. Think: DB=GPU, SQL=GLSL, what's actually executed -> compiled code.

I disagree it's responsibility of the tool. Program should just reach out for files and some higher order or meta runner should trace what the process does. One of the commenters mentioned `strace`, this is the correct approach, but should be done in well engineered way.

Other way is to run program in symbomlic interpreter and trace what it wants to read in any of the branches.

Thanks for becoming a mirror (although what happened was you wrote a "mirror" comment of my comment, not me), however I'm really interested in better tools. None of the tools I know fully satisfy me. GUIs are less comfortable and slower than TUIs, of course depending on task you want to accomplish. If comes to thing like Emacs w/ Magit + evil mode which is ~(n)vim and task which is text editing or even maybe code editing - can't really find anything better more versatile and fast.

I'm interested in merging all known ideas (including Smalltalk IDEs) and moving forward.

Perhaps I have higher expectations which I didn't explain anywhere. Hard to tell full story in short text comment.

You're defending n(vim)+plugins, not naked (n)vim and I agree it can be taken very far and can start to look like Emacs which integrates multiple external processes in single place. Actually anything can be taken anywhere with sufficient time and effort. That's the secret of transmutation. But you won't overcome the fact it uses terminal by default which I find subpar compared to pixel perfect GUIs. Terminal UIs are useful for sure, but I see them as a hidden cry of despair when people are trying to avoid touching modern GUI systems. The strength of vim (vim motions) should be stripped away and be embeddable in any other system as a leaf, not the other way around where (n)vim is in the center and other pieces are plugged into it. I know it's happening and you can use native nvim inside e.g. VSCode which is great.

I know there are tools like GVim etc, but again, they are created with high engineering effort which for some people is simply pleasant to undertake.

Again, I'm not trying to defend or favor any system, I'm actually using at the same time VSCode (for best TS intellisense), WebStorm (for refactors), nvim (for quick browsing and small config file edits) and Emacs (for Magit). My computer is my tool, not single thing inside it.

I tried to understand what vim/nvim is all about and why people love it so I've learned it a little bit. I grasped the Zen of VIM, it's actually very comfortable to navigate files and files tree assuming Ctrl is swapped with Caps Lock and you don't use ESC but Ctrl+] or jk/jj. BUT. But. but... VIM was shining when it was designed and created, it doesn't shine that much today, because for working with code you need things like LSP, syntax awareness etc. Thing like VS Code with Emacs cross platform keybindins AND WITH smartSelect is amazing for me.

Go to VSCode, put it into your `keybindings.json`:

    {
        "key": "ctrl+cmd+j",
        "command": "editor.action.smartSelect.expand"
    },
    {
        "key": "ctrl+cmd+k",
        "command": "editor.action.smartSelect.shrink"
    }

go to TS file and press keybinding multiple times to see how it grows/shrinks. Having Emacs keybindings like C-w, C-y, C-d (I'm using it to move char left), C-S-d (word left, S is shift, I'm using right one) and more I feel like flying through things like selecting block, expression, function, moving in and out etc. I guess Emacs people using paredit feel something similar taken to the next level.

Ideas in VIM are still brilliant, the same goes for Emacs, but they both need to reincarnate in modern skin taking pixel perfect GUIs with proper animations to the extreme. In fully multithreaded and multiprocess environment.

I think this is important: finish your project in bigger context where your project is a piece needed in higher level picture. Don't finish project just to finish it. This attitude solves problem of motivation, because you naturally finish the project without forcing yourself. Masons don't lay bricks to have bricks laid down, they want to build a house. Of course it much more complex than that, some people are just not types of makers and "finishing projects" is not their cup of tea.

How submodules should be done properly:

  1) define somewhere in the repo that it's a "compound repo", a "workspace" etc - name is arbitrary, This is our repo "R",
  2) for certain paths in the repo, mark those paths as an aliases to other repos identified by a repository URL/path. These our "r" repos.
  3) for every git command executed inside repo "R", run appropriate commands in the background for each "r" repo only if repo "r" was affected by changes initiated in repo "R".
  4) If you made changes to repo "r" directly and then returned to "R", after "git pull" you should see nothing else than standard git diffs, conflicts etc. You should not run anything like "sync"/"refresh" etc. Only git pull/rebase/merge etc.
  5) Commit in repo "R" which is only responsible for bumping repos "r" should be handled by git submodule system transparently for the user of "R". I'm not a git expert to tell what kind of commit should be used here. Any ideas? You should commit seeing diffs of course, not some commits hashes.
  5) THAT'S IT.
Everything should work recursively, e.i. you should be able to do 10 layers of "r" repos. Each n-th "r" repo acts as "R" repo for n+1 level repo. Ten fold commit should work like transaction, e.g. if any of layers between 1 and 10 has failing precommit hook - the whole operation should fail.

Please help me find potential problems. thx!

We could have amazing HTML/CSS performance if we had programmable "HTML to bitmap" caching. But: a) it's not secure if we can render HTML to bitmap and send over network, b) cache invalidation problem - we'd have to invent mechanisms to lock HTML against further changes or track changes and rerun "HTML to bitmap" procedure.

All this is not suitable for web, but for thing like Elector - hell yeah. HTML to bitmap extension would be really welcome. Then you could render UI in WebGL or WebGPU. Adobe Flash had something similar if I recall correctly.

Here’s my quick and dirty prediction of what will happen with software in the future. The goal if this writeup is to collect feedback and spark discussion. Many of the statements can be purely wrong - please take them with a grain of salt.

Thanks!

Programming can be thought as a medium similar to paper+pen or video, but it's interactive. Ask yourself then: "Is writing a 'young man's game'?". Of course not. Then the question should be reframed to "what kind of programming is young man's game?". Find appropriate answers. Then think what kind of software cannot be written or even thought by a young man.

Escape the bubble you're currently in and start thinking in a broader way.

Why Rust? 4 years ago

JS is the best language for web - and generally for high level systems design - and honestly I don't know why people don't want to see it. Good parts of JS are: first class functions and closures and prototypical inheritance. Find decently popular language with those things implemented well, good luck. Rest of JS features are a noise, improvements of developer work ergonomics (all those let/const, modules, async/await and what not etc) and unfortunately pile of bad decisions which cannot be undone because web has to work correctly and do not break constantly.

JavaScript really is a Scheme in disguise with a little bit of Smalltalk. Which really is good. If you don't like junk coming from {}+[] - don't use it, but I consider the lack of errors thrown to be a correct behaviour. Use TS or any other linter to control stuff.

As we can see, Clojure wasn't accepted widely despite the fact it also has first class functions and closures. In my opinion the answer is simple: people want to have syntax for stuff which we agreed is good. Using macros and ((())) is not what people want to do long term.

I'm arguing for B.

What I care about is timeline, assets, library, keyframes, movie clips, drawing tools, text formatting, tweening and much more. All in one package, cmd+enter to see the output. Maybe even these days cmd+enter is too much, the output should be immediate and even better - live. Bret Victor would not be happy about not-live (dead!) scene. Definitely I don't want to resurrect old Flash. TypeScript is much nicer than AS3, even though AS3 had E4X which I remember to be quite powerful even compared do poor JSX.

I think you're right about missing GC and shipping `List`, `Set` etc. to the user as a part of the runtime. But, if that can chunked out and be stored on a CDN and downloaded only once for a browser session, then this problem won't hurt that much. Once GC is added to the platform I'd love to see Figma-quality reincarnation of Flash in an B-option (from your post) manner.

My advice is this: improve yourself/your knowledge to the point then you see all those libraries/frameworks have common parts implemented from different angles and all are very subjective because the authors had personal opinions. Then you'll realize you don't have to chase everything, just those things which really matter to you. I can recommend watching Alan Kay's videos on YouTube and understand what Smalltalk was, what were things like HyperCard etc. I really see web and web frameworks as -- poor in some aspects, like meta-circularity, or quite strong, for example in multimedia support -- reincarnation of those earlier ideas from 60s and 70s.

12 had amazing form factor, but it was great only for native apps, web apps were running horrible on it. But it was beautiful at that time, it was first macbook with various colors? Even once one lady at coffee shop approached me and asked what version of MacBook it was. No no... that's end of the story :)

Because "human capital" (no matter how dehumanizing it sounds) is the best one, people with money want to invest in people with great minds. Otherwise investors's money will evaporate because of for example inflation. Also, throwing couple of millions into a growing company means "i want to be part of it and take back some revenue hoping it'll be huge".