HN user

pbohun

606 karma
Posts12
Comments118
View on HN
Making 4 hours ago

If all you care about is the end product and not how it's made, then you never become a better person. Your capacity for thinking and solving problems will never grow. You will never be an expert. Experts care about the process.

Of course, you may not care, and that's fine. It's important that people not be delusional about this though. A person with no medical knowledge and an AI will never be as good as someone with prodigious medical knowledge and an AI. The same is true for any profession, whether programming, music, writing, etc.

There are some good points here, but I disagree that programs are slow because they are accessible. Computers are ridiculously fast, and it doesn't take more time to display a string in Japanese than it does English.

The problem is ultimately with how the software is structured from the the start. Pressure to release fast, and the fact that most software engineers are not experts, means that nearly all software systems and libraries have poor design. They will be bloated and buggy, and difficult to work with.

Poor design means that development velocity dramatically slows as a project matures. Frameworks ensure that you start development fast, but eventually it takes a week to add a button.

Honestly, I think starting from win32 again would be a breath of fresh air. Also, note that I described it as an option, no one would be forced on Windows Lite. It was my own speculation that it would become popular.

No, the idea is that the actual key is the XOR of 3 completely independent keys. I think you were thinking of XORing a key with itself 3 times, which would just return the original key.

In the book, there is a cargo ship carrying 1/3 of a OTP. Other two other ships from two other companies are carrying the other thirds. This actually is a fairly decent method of transporting a OTP (I'm assuming there's some kind of physical security preventing tampering).

The book even talks later on about how only using the pad isn't enough, since it provides no proof of authorship or tampering. Vinge did a pretty good job w/compsci in the book.

I really like Iosevka, and though I haven't used it, I do like Berkley mono. Maybe I'll incorporate this into my list of terminal fonts in the future. It does look pretty sharp.

There need to be some serious regulations around prediction markets. I'm not sure they should even be legal. These "markets" are encouraging large amounts of fraud and manipulation. As far as I can tell, they offer no positive effect to society.

One possibility is that most of the code that matters is being written by hand, while enormous amounts of code are being generated for other things. People are being evaluated on their AI usage after all.

You probably also don't use a calculator because it uses a scary language called arabic numerals. Why write 123,456 when you could write out in english: One Hundred Twenty-Three Thousand Four Hundred Fifty-Six? English is your programming language and also your math language, right?

It's not ape coding. It's skill coding. People who don't have the skill to do math and logic ask others to do it for them.

The reason we have programming languages is the same reason we have musical notation or math notation. It is a far more concise and precise way of communicating than using natural languages.

We could write music using natural language, but no one does because a single page of music would require dozens of pages of natural language to describe the same thing.

This page was put together very well. It has interactive illustrations when needed (not excessive), and the explanations were informative yet concise. I also like how it brings up other uses of quadtrees, such as for images. This encouraged me to think about how they might be used elsewhere.

As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to.

You could imagine creating a modified Go assembler that is more generic and not tied to Go's ABI that could accomplish the same effect as LLVM. However, it'd probably be better to create a project like that from scratch, because most of Go's optimizations happen before reaching the assembler stage.

It would probably be best to have the intermediate language that QBE has and transform that into "intermediate assembly" (IA) very similar to Go's assembly. That way the IL stage could contain nearly all the optimization passes, and the IA stage would focus on code generation that would translate to any OS/arch combo.

People are correct I didn't explain my position.

LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.

Swift: I was very excited with the first release of Swift. But it ultimately did not have a very focused vision outlined for it. Because of this, it has morphed into a mess. It tries to be everything for everyone, like C++, and winds up being mediocre, and slow to compile to top it off.

Mojo isn't doesn't exist for the public yet. I hope it turns out to be awesome, but I'm just not going to get my hopes up this time.

There's no way to say this without sounding mean: Everything Chris Lattner has done has been a "successful mess". He's obviously smart, but a horrible engineer. No one should allow him to design anything.

Edit: I explained my position better below.

It feels like everything is falling apart and getting worse. Yet somehow people are racing to produce AI slop faster. If software eventually collapses under its own weight, things might be so borked we have to bootstrap everything from scratch, staring with assembly.

Not quite. Erlang uses the Actor model which delivers messages asynchronously to named processes. In Go, messages are passed between goroutines via channels, which provide a synchronization mechanism (when un-buffered). The ability to synchronize allow one to setup a "rhythm" to computation that the Actor model is explicitly not designed to do. Also, note that a process must know its consumer in the Actor model, but goroutines do not need to know their consumer in the CSP model. Channels can even be passed around to other goroutines!

Each have their own pros and cons. You can see some of the legends who invented different methods of concurrency here: https://www.youtube.com/watch?v=37wFVVVZlVU

There's also a nice talk Rob Pike gave that illustrated some very useful concurrency patterns that can be built using the CSP model: https://www.youtube.com/watch?v=f6kdp27TYZs

They're not using the dangerous way because of syntax, they're using it because they think they're "optimizing" their code. They should write correct code first, measure, and then optimize if necessary.

The first Go proverb Rob Pike listed in his talk "Go Proverbs" was, "Don't communicate by sharing memory, share memory by communicating."

Go was designed from the beginning to use Tony Hoare's idea of communicating sequential processes for designing concurrent programs.

However, like any professional tool, Go allows you to do the dangerous thing when you absolutely need to, but it's disappointing when people insist on using the dangerous way and then blame it on the language.

https://www.youtube.com/watch?v=PAAkCSZUG1c

That's not what the comment said. It said, "How about a Rust to C converter?..." The idea was that using a converter could eliminate the problem of not having a rust compiler for certain platforms.