News for hackers. Stuff that matters.
Re:Ode to the M1 by ramesh31 on Sunday August 13, 2023 @01:34AM (#37106994)
>I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world.

Yes, so we can go back to writing a hundred lines of imperative code to render hello world.

Re:Ode to the M1 by lylejantzi3rd on Sunday August 13, 2023 @01:59AM (#37107109)
4 in c. 11 in assembly. Not so bad, really.

https://i.imgur.com/r2WRnZk.png

Re:Ode to the M1 by dijit on Sunday August 13, 2023 @02:35AM (#37107238)
I was about to make a joke about how many lines are required for an electron hello world but it was even more than I expected.

11 for the HTML document template

7 for the boilerplate package.json

3 more for the scripts addition to package.json

3 more for the “devdependencies”

20 for main.js

from: https://electronjs.org/docs/latest/tutorial/quick-start

A fairer assessment would be C++ with Qt to be honest though.

Re:Ode to the M1 by SubjectToChange on Sunday August 13, 2023 @02:41AM (#37107269)
write a hello world application in gtk or qt and see how much assembly you get.
Re:Ode to the M1 by GhostWhisperer on Sunday August 13, 2023 @03:15AM (#37107446)
let's move the goal posts to doing it in brainfuck since we're at it
Re:Ode to the M1 by SubjectToChange on Sunday August 13, 2023 @04:20AM (#37107787)
What goalpost did I supposedly move?
Re:Ode to the M1 by 5- on Sunday August 13, 2023 @04:32AM (#37107855)
x86_64 assembly, gtk3, 21 lines / 19 instructions

build with e.g. gcc hw.s `pkg-config --libs gtk+-3.0`

  .globl main;main:
  push %rbx
  xor %esi, %esi
  xor %edi, %edi
  call gtk_init@PLT
  lea .HW(%rip), %r8
  xor %edx, %edx
  xor %esi, %esi
  mov $2, %ecx
  xor %edi, %edi
  xor %eax, %eax
  call gtk_message_dialog_new@PLT
  mov %rax, %rbx
  mov %rax, %rdi
  call gtk_dialog_run@PLT
  mov %rbx, %rdi
  call gtk_widget_destroy@PLT
  xor %eax, %eax
  pop %rbx
  ret
  .HW:.string "Hello World!"
Re:Ode to the M1 by SubjectToChange on Sunday August 13, 2023 @04:47AM (#37107934)
Are you sure you couldn’t wrap that up in another library and just do everything in a single call?
Re:Ode to the M1 by 5- on Sunday August 13, 2023 @04:48AM (#37107943)
Re:Ode to the M1 by wiseowise on Sunday August 13, 2023 @04:55AM (#37107980)
That’s super ironic that you’ve shown screenshot from a web application.
Re:Ode to the M1 by lylejantzi3rd on Sunday August 13, 2023 @10:20AM (#37110285)
Why, thank you!
Re:Ode to the M1 by johnnyworker on Sunday August 13, 2023 @12:45PM (#37111583)
To the CPU it always boils down to sequences of instructions operating on data, so the syntax sugar put on top has be undone first, the abbreviations have to be unrolled, some way or another.

But more importantly it's really not about the lines you code write once, or very few times in comparison -- it's about the computer does any time the application starts up on any machine, or any user does something. Obviously, to an extent. You wouldn't write a thousand lines of code instead of 100 to make something that is already very fast 10% faster. But I certainly would write 10 line instead of 1 if it meant the code is 10 times faster. It's just typing after all.

Re:Ode to the M1 by ramesh31 on Thursday August 17, 2023 @01:26PM (#37165182)
My point was that CPU cycles mean nothing now. Compared to programmer cycles they are effectively free. So stuff it into RAM and forget about it. Why not? Complexity is bad, and being able to hide it (effectively) is good. I shouldn't be thinking about pointer allocation when building a a text input box for a UI.