Hacker News Reader

Comment by spectramax | Hacker News Reader

I disagree. There is always value in learning something simple and master it than learning something complex and barely scratching the surface.

It teaches you fundamentals, especially on an embedded system such as R-Pi.

The first language I learned was C on an ARM processor. Learning about registers, bit manipulation, seeing how compiler optimizes the code based on GCC flags, understanding pointers, memory management, the whole thing is difficult for a beginner but to me, it was immensely helpful. I also love Python/Julia/Java/JavaScript but man it makes you appreciate neat things higher languages offer.

One day I want to build my own 8-bit computer from discrete gates. I’m sure it won’t be a waste of time.

View on HN

https://www.nand2tetris.org/copy-of-cool-stuff

This is definitely not a waste of time. But though building a physical ALU from TTL is feasible, constructing a reasonable amount of memory would be a waste of time and money.

Once you have written the nand2tetris HDL for the hardware, you could translate it to Verilog and burn an FPGA quite easily.

This is the coolest thing ever, thank you!

I'm an electronics engineer who started to learn programming Assembler on PIC16 micro-controllers. My arguments is not against learning the fundamentals. I just know from teaching that the primary problem people have when learning is that they get stuck and stop. Making GUIs in Python (given good educational resources, like a book) will give results much faster, and more quickly become a practical skillset for GUI programming and other useful tasks.

For learning C and starting to poke at low-level embedded stuff I would recommend starting with Arduino (and then into plain AVR) - and not go anywhere near a GUI toolkit.

There is a reason we don't actually throw kids into the deep end when teaching them to swim. Most of them would just drown...

I agree with you if you are talking about Python vs C.

But a new GTK2 book sounds like teaching Python 2 for beginners.

The author does touch on this on page 76 of the book (quoted below)

GTK 2 and GTK 3

One thing worth mentioning at this point is that there are two versions of GTK in use. The current version is GTK 3, and this is still under active development – it changes quite a bit between releases.

For this reason, many people prefer to use the older version, GTK 2. This offers most of the same functionality, but it is stable code which doesn’t change very much any more. Some say that it is always better to use the latest and greatest version of anything, but more cautious old engineers (like your author…) tend to prefer the older version that has had a lot more testing and with which people have stopped fiddling about! In terms of the examples we are looking at here, there aren’t that many significant differences between the two, but just to be clear, the examples in this book will use GTK 2.

GTK+ 3 is stabilized now. GTK 4 sees active development, and hopefully a first release this year.

The only problem I have with GTK3 is that the quality of the documentation I've found is...less than ideal. Broken links and extremely terse descriptions of parameters to calls are a common complaint for me.

Which, like Gtk 3 to Gtk 2, is also backwards incompatible so using Gtk 3 also wont be future proof (and Gtk4 wont be either, for that matter, unless the Gtk developers stop breaking their library every major version and decide to provide a stable API people can target - but considering they cant even decide on a stable way to make themes, i have little hope for that).

GTK2.0.0 was released 17 years ago. GTK3.0.0 was released 7 years ago. GTK2.24 got its last patch release 2.24.32 about 1 year ago.

10 years being the mainline version, and having a supported compatible version for 16 years is pretty darn impressive! If GTK4.0.0 comes out next year, then GTK3 will have had 8 years being the mainline version. Its not quite win32 levels of stability, but it is not like they break this stuff every year or something...

Thing is, just last month i wanted to play an older game that for some reason was linked against Gtk1. And pretty much every application made with Lazarus today is linked against Gtk2 (as the Gtk3 backend is still in a very prealpha state) and i'm sure there are other similar situations. And as you can see with this book, people are still working with Gtk2.

At this point it doesn't matter that it was released 17 years ago, what matters is that there are programs using it.

Honestly, i can see Gtk1 to Gtk2 breaking compatibility since they probably did some blunders and all and it wasn't very long lived anyway, but Gtk2 to Gtk3 should have kept backwards compatibility - GUI libraries are important foundation for a platform and breaking changes breaks every application that relies on them. Instead what the developers did was not only break Gtk3 but not even try to design an API with Gtk3 that would allow Gtk4 to be backwards compatible.

It is frustrating if as a developer you want to ensure your program keeps working in the future and have the foundation it relies on sabotage you. I can release a Win32 application today and i'm certain that if people are still using x86 Windows desktops, it will work in 20 years. Hell, chances are it'll still work in Linux thanks to Wine - whereas the only way i'd get the same sort of compatibility with a "native" UI library would be to write my own toolkit and use X11 directly (and even that assuming Wayland developers wont have convinced everyone to drop X11).

Sometimes i'm just considering to just target Win32 for my stuff and tell people use Wine for Linux and macOS, it'll be more likely to work in the future than any native UI library.

If the GTK1 based game had bundled its dependencies, it would have worked today as well. I think better solutions for that is the way going forward, not requiring devs to maintain compatibility forever.

Expecting every application to bundle all shared libraries it depends on is absurd, it invalidates all the benefits shared libraries provide - like them being shared with other programs, having shared updates and of course new features. As an example, if Gtk3 was backwards compatible with Gtk1, the game not only would work but the UI would be a native client for Wayland despite the game being released a decade before Wayland was a thought at anyone's mind. And to stick with games, you can see another good example why bundling shared libraries is a bad idea: old games that use SDL often need their SDL copy replaced with a new one to work since the old one is using methods that in the meanwhile were invalidated (e.g. using OSS instead of ALSA).

Outside of games, for software that touches the Internet you probably also want libraries to get shared security updates.

And of course having to bundle 50+MB of libraries and data (themes, etc needed by a GUI toolkit and any other data by other libraries) for a small executable is a ridiculous idea by itself.

No, a desktop system should provide some minimum functionality that desktop applications can rely on and keep that functionality stable so that application can keep on working.

I'm only expecting applications that don't update their code in 10+ years to do so.

Systems like Flatpak have a framework system where it is possible to have a shared runtime of dependencies that multiple applications can use. A GTK1 runtime could exist (or maybe does?), for example.

Yes, Flatpak sounds like it solves the compatibility problem (although it remains to be seen in practice what issues itself might have) but it still is half the solution: a Gtk1 could exist, but since that Gtk1 runtime is still the abandoned Gtk1 libraries (which were abandoned because Gtk2, Gtk3 and now Gtk4 decided to break backwards compatibility), it doesn't provide any new functionality and/or fixes to programs linked against it. In contrast in Windows, since Win32 is both backwards compatible and continues to get developed, if for example i use a program from Windows 95 that uses the common file dialog, i still get to see the overlay icons from my VCS extension or the compressed file status. On the other hand Gtk1 would still show the old Motif-like open dialog that was written back in the late 90s.

Or perhaps more fitting to modern Linux desktop, Gtk1 and Gtk2 will not support Wayland nor any new functionality introduced for scaling (did you know that, despite common narrative from Wayland fanboys, X11 already provides the necessary functionality to implement per-monitor and even per-window scaling with pretty much 99% of the same code that a toolkit would need for Windows 8+ scaling, that is most likely already written? It only needs some cooperation from the window manager and this sort of code could even be implemented for XWayland.... but it needs a bit of modification from the toolkit's side too and while it could be done for Qt5 and perhaps Gtk3, it'd need Gtk2 and especially Gtk1 to be worked on, which wont happen - on the other hand, if Gtk2/3/4 were backwards compatible, all programs would benefit from such new functionality).

The embedded environment is what makes this setup make sense. But in the general case, C is less than ideal for GUI programming compared to what's available in other languages, because of lack of first class closures and more complex data types (or at least classes). Otherwise you are basically in the 80s doing Win32 GUI programming all over again.

What do first-class closures have to do with anything?

Being able to pass a closure (lexically scoped anonymous function) as an event handler is invaluable in GUI programming.

So you think C can't do that? Of course it can. Anything you want to create, C can handle it just as well if not better.

C doesn't support closures natively, so have fun building it up yourself. You can pass a function pointer. That's it.

My point is, that in C, you can do anything, including creating closures and passing them however you wish.

With enough coding, you can "do anything" in any Turing complete language. This is meaningless. It doesn't mean it is advisable (simple, maintainable) to do so. C does not support a syntax for closures, so you'll really just be calling functions with an 'environment' arg or something similar. What's the point?

My point is that he claims C can't do closures or pass them either. Follow the thread.

As far as being turing complete, CSS is supposedly that, also, so good luck with that.

When people say a language supports closures, they are generally talking about syntax. C does not support a convenient syntax for closures, period.

Here's a guy who developed a closure "library" for C: https://nullprogram.com/blog/2017/01/08/

It's clever, but he actually had to resort to assembly...

You think everyone not using C is just being idiots?

I'm doing GUI programming for many years (from the DOS days) and while closures can be neat for small stuff (like updating an object field and calling some sort of refresh function for a visualization of the object when a GUI widget that represents the field changes), they are certainly not invaluable and you can do GUI programming perfectly fine without them - just pass a method pointer (obj+method) for C++ and similar languages (e.g. "procedure of object" or "function of object" in Object Pascal) or just a function address that takes an extra pointer (or whatever) argument that is given during handler registration (e.g. in a C toolkit of mine you register stuff with "register(widget, event, handler, param)" and handler is defined like "handler(widget, eventinfo, param)").

Actually, IMO if you are using closures for events that are more than 5 or so statements (i'd say lines but people love to pack their lines with multiple statements), you are doing a disservice for every poor soul who will have to understand your code later.

There's a school of thought which considers complex data types to be more a part of problem then a solution. You may disagree with it, but nevertheless one certainly doesn't need complex data types to write GUI (or anything) effectively.

Also, in this universe Win32 API was released in 90s, not 80s.

The complexity should be the same no matter what language you use, but how you structure and organize that complexity changes drastically. Hence in Ruby it takes only 2-3 lines of code to accomplish what in Java requires a few ItemFactories.

#MandelaEffect

> Win32 API was released in 90s, not 80s.

Yeah, well, kinda... technically you are correct but Win32 is 99.998% backwards compatible (as an API, not ABI) with Win16 which was first released in the 80s.

Its possible you may have come across this but if you havent already it speaks to what you just said https://www.evanmiller.org/you-cant-dig-upwards.html

This is exactly what I wanted to learn. I really wanted to 'see' C in action at lowest level. This aspect of programming is what I am curious about.

But I never found a decent beginner friendly resources.

Anyone reading this comment, please chime in with your suggestions.

If you want to see C at it's lowest level and understand where it shines, I'd recommend the embedded and bare-metal realms. This Raspberry Pi tutorial set, for instance:

https://github.com/bztsrc/raspi3-tutorial

It's also fairly popular for emulators, since it's types are orthogonal and it's low level design is well suited to designing a pseudo-machine. It's definitely being displaced in that realm by C++/Rust/Nim/etc though.

Thank you very much!!!

If I may add my two cents... I highly recommend reading through the standard library and then looking at how they are implemented in actual C. The string library is probably the most important, this is where most people mess up!

If you can figure out pointers and how to actually get the size of things (sizeof(*char) doesn't get you the size of what it is pointing at... it gets you the size of a pointer which varies depending on the architecture. sizeof(myArray) doesn't give you the number of elements in an array, it gives you the number of bytes your array can hold, to get the number of elements you must do sizeof(myarray)/sizeof(myarray[0]). sizeof() is a compile-time operator, it knows nothing of runtime) you will be pretty much 99% of the way there.

https://en.cppreference.com/w/c/string/byte

https://github.com/lattera/glibc/tree/master/string

Hasn’t it always been the case that the current generation skips learning about useless lower layers used by older generations? How could it be that the layers you grew up with and learned are the special ones which are still useful, when all the layers which came before, which people at the time thought essential, have turned out not to be so?

I.e. why is it that C and assembler is “fundamental”, but electronics is not?

(I have written about this before: https://news.ycombinator.com/item?id=19106922#19113359 )

I mean when I went to university we absolutely went over the electronics side of things. Certainly not to the same depth as an electrical engineer would have, but it was covered.

Reply on news.ycombinator.com