Live data from Hacker News

Is true hacking dead? What we lost

c0de517e.blogspot.com

101–110 of 194 posts

Re: Is true hacking dead? What we lost

#101
post #5

I've never understood the appeal of hot-patching and full process image save and restore. Yes, this technology is neat for some use cases, but as a fundamental way of computing it's broken, because it throws reproducibility out of the window. Reproducibility is everything in complex systems, and being able to reset and start fresh is powerful. Evolution figured that out as well. It's why basically all species propaga…

As soon as one works on a non-trivial piece of software and has a team >2 SCM becomes important. There was one SCM system for PP Smalltalk if memory serves right called Envy but it was quite expensive. But even more important than SCM is a module/library eco system. We can’t trade without reproducibility. Without it we are destined to re-invent the wheel. There is value in reinventing wheel - it is entertaining and s…

You always have a team >2, unless you're just writing a quick throwaway hack. Your future selves are members of the team, and there might be quite a few of them over time as you simply forget what you were working on earlier.

Re: Is true hacking dead? What we lost

#102

There was a time when I used to fret that the era of tinkering was coming to an end. Crypto was going to be illegal, they were going to put DRM on speakers, and our computers are designed to be completely locked down to the degree that you can't even add more RAM to a MacBook Pro. However, I think that the rise of Linux, Raspberry Pi and Arduino, OSS and Github and massive package repos for every language, Adafruit,…

Please use Godot rather than Unity. Hackers and educational institutions should not be advocating for proprietary software that locks in its users.

Re: Is true hacking dead? What we lost

#103
Nice ideas. I think that complexity can be the enemy of “hackability.”

Some environments like Pharo Smalltalk are simple enough to dig down to see how stuff works, and I would add simple Lisp implementations.

When I first started using Ruby and Rails, I kept the source code to Ruby and for Rails available for perusal and it was more or less understandable. Not so much now. Complexity.

I think that the Racket ecosystem will get more hackable once the codebase sits on top of Chez Scheme. Racket is well documented: 18 months ago I wanted to import trained weights and biases from a trained Keras/TensorFlow model into Racket and implement a runtime - fairly easy to do with good documentation and good library support for fast linear algebra.

Too bad that more people don’t spend more effort on hacking activities because really understanding tools, modifying code, etc. is fun and I would argue a good career move.

EDIT: added 1 word for clarity

Re: Is true hacking dead? What we lost

#104
post #88

Earlier quoted context omitted.

> complex solutions Puzzles aren't really about that. It's about making a model of a problem and finding solutions to it. Complex solutions are as bad in puzzles as in any other area. Not sure what you mean by "clever" (maybe "clever" as in unreadable code). Sometimes you come to an aha moment and realise that you can solve something in a trivial way, aka clever way, and that's a desirable event.

A puzzle will more often than not have one right way to do it, unlike real engineering problems which are made of trade-offs, and that one way is unintuitive, otherwise it wouldn't be much of a puzzle at all.

A puzzle is just a packaged problem. I think it's hard to argue that certain puzzles are more prevalent than others. This weekend we were doing these puzzles where you have to align unique pieces into a specified shape. It's basically a bruteforce search. The creativity is expressed in how you reduce the search-space and how you memorize the alignments you've already tried. There's definitely more than one way to do it.

Re: Is true hacking dead? What we lost

#105

I don't think true hacking is dead, its just lost in a sea of non-hacking. The number of students who could write code in my high school of 2000 was perhaps 35. Those 35 were amazing because they had to work to get access to a computer, so we had already eliminated everyone who was just "oh that's too hard". Of the 35 perhaps a dozen kept at it beyond one class in BASIC. In my daughter's similarly sized highschool 40…

> Compulsive puzzle gene Did you observe this in _all_ of the mentioned 35 students in your high school? Do you think that an aptitude for puzzles is a de-facto pre-requisite? I know that it shouldn't be, but I'm wondering if you have actually met people who are not good with puzzles but are extremely good when it comes to making a computer do things.

I think there are two approaches of computer lovers. One is for the puzzle solvers, and one is for the escapers.

Re: Is true hacking dead? What we lost

#106
post #88

Earlier quoted context omitted.

> complex solutions Puzzles aren't really about that. It's about making a model of a problem and finding solutions to it. Complex solutions are as bad in puzzles as in any other area. Not sure what you mean by "clever" (maybe "clever" as in unreadable code). Sometimes you come to an aha moment and realise that you can solve something in a trivial way, aka clever way, and that's a desirable event.

A puzzle will more often than not have one right way to do it, unlike real engineering problems which are made of trade-offs, and that one way is unintuitive, otherwise it wouldn't be much of a puzzle at all.

Even when there is only one solution there is generally a vast array of possible approaches to solving it. A Rubik's Cube for example does not care about the intermediate states.

Re: Is true hacking dead? What we lost

#107

There was a time when I used to fret that the era of tinkering was coming to an end. Crypto was going to be illegal, they were going to put DRM on speakers, and our computers are designed to be completely locked down to the degree that you can't even add more RAM to a MacBook Pro. However, I think that the rise of Linux, Raspberry Pi and Arduino, OSS and Github and massive package repos for every language, Adafruit,…

Thank you for mentioning Roblox because I see kids hacking way more interesting stuff there than anything I’ve ever seen done on a Raspberry Pi. And the kids are learning Lua!

Re: Is true hacking dead? What we lost

#108

There was a time when I used to fret that the era of tinkering was coming to an end. Crypto was going to be illegal, they were going to put DRM on speakers, and our computers are designed to be completely locked down to the degree that you can't even add more RAM to a MacBook Pro. However, I think that the rise of Linux, Raspberry Pi and Arduino, OSS and Github and massive package repos for every language, Adafruit,…

Please use Godot rather than Unity. Hackers and educational institutions should not be advocating for proprietary software that locks in its users.

This point was made a lot in the article - Hackers didn't care about Open Source or the ideology. I tend to agree with that.

First it's "don't use Unity", then it's "don't publish your Godot game for Windows", then it's "don't publish your Godot game in a form that requires proprietary graphics drivers", then it's "don't allow your game to run on Ubuntu", and so on. There's always another step to achieve ideological perfection.

Perfect is the enemy of done. Getting stuff done is the important thing.

It's much better to raise kids knowing that they can make their own games than not. If that's easier to do on Unity, then that's the way to go.

Re: Is true hacking dead? What we lost

#109
post #32

There was a time when I used to fret that the era of tinkering was coming to an end. Crypto was going to be illegal, they were going to put DRM on speakers, and our computers are designed to be completely locked down to the degree that you can't even add more RAM to a MacBook Pro. However, I think that the rise of Linux, Raspberry Pi and Arduino, OSS and Github and massive package repos for every language, Adafruit,…

Hacking is just interesting only if you are not following any "tutorial". Today you can run an embedded linux under 10 minutes with less that 20 bucks with a RPI by reading some tutorial or watching a youtube video. What's the fun about that? I remember too hacking my commodore and the only help I had was just a book in a strange language (english in my case) and my dad (he was into 8086 at that time) when I was a ki…

Well, yeah, the video tutorials / step by step guides are for people who do not care about hacking, or deep understanding of how the system works. It is like McDonalds of software world - ypu are no loger hungry, but the food is pretty bad.

You can always grab a book (and a manpage, and a sample config) and do it the old fashioned way. It will take longer, but will teach you more.

Re: Is true hacking dead? What we lost

#110
post #88
post #70

Earlier quoted context omitted.

Puzzles don't interest me much, but composition, building and designing things does. When hiring engineers, I sometimes worry that too much puzzle-orientation shows a bias towards "clever" solutions - and complex code - where not necessarily warranted. There's definitely a place for that kind of focus, but it's usually quite low down in the stack, and that's increasingly far away from business value these days.

> complex solutions Puzzles aren't really about that. It's about making a model of a problem and finding solutions to it. Complex solutions are as bad in puzzles as in any other area. Not sure what you mean by "clever" (maybe "clever" as in unreadable code). Sometimes you come to an aha moment and realise that you can solve something in a trivial way, aka clever way, and that's a desirable event.

For sure. However most code doesn't require "aha moments"; it requires readable code with tests that cover edge cases, following the same pattern as similar code that does similar things.

The worry around puzzle orientation is when someone e.g. takes advantage of an obscure feature or does something unusual for a performance gain at the cost of readibility or maintenance. I've seen several repeated instances of clever people writing complex code because they could, and spending too little time thinking about whether they should.

There's a place for that kind of thinking. It's usually when non-functional requirements are limiting factors; minimizing memory, CPU time, network round trips, etc.

Post reply on HN