Assembly is a type of programming that is unlike most programming languages, and as such, would be a really tough introduction to the field.
Can you explain a bit more about how you became interested in assembly and programming the Apple II? And specifically, why you want to start the journey towards programming there?
The original magic system from Final Fantasy 1 (you can only cast N spells per magic level, maximum of 9) is a copy of the system from Wizardry. The only difference you have to type the spell name to cast it in Wizardry, and you get a menu in Final Fantasy.
Freshpaint is hiring! We're a YC- and Intel-backed company SaaS platform that provides a codeless customer data platform that is default-safe for companies that need to work with sensitive data, like protected health information.
I like the idea of deliberate learning! I also really like the idea of focusing on how to maximize the amount of learning you do, and choosing when to strategically focus on that. So this is really cool general advice, and honestly the feedback that is outlined really could apply to any raiding guild, whether casual or not. Or also just, you know, people. Any people. It's good advice.
I had to set aside the framing device of a raiding guild, though, because the way it's used isn't realistic. It seems to me there's an assumption that learning is happening in a closed system, where learning can only happen through experimentation. That's not how MMORPGs work--people share experiences all the time, both inside and outside the game. People also raid outside of their own guild, which means that raid attempts can include people who've done this before, and can essentially help your guild by talking you through how it's done in-game.
So, in the general case, any attempt at learning within some reasonably closed system in which no learning can happen outside of experimentation, and when experiments are limited in quantity, certainly _must_ try to maximize what you can learn for every experiment. But casual raiding guilds do not fall into that category.
A lot of advice I've seen (such as this) postdates much of the standard library implementation by quite a bit. I could not, however, suggest that the current design for crypt is good or bad, for I have not used it often enough to offer a worthy opinion.
People seem to really click with the net/http design, and that does seem well done, but I imagine the standard library itself is a bit unevenly architected.
Abstractions are not a bad thing, but early abstraction often lacks understanding of the problem to solve. Abstraction is complexity. We often need complexity, but we should not add complexity without cause.
And I don't think this is a Java vs. Go thing. Let the program, or the problem if you will, prove to you where you need abstraction.
It would be neat if MachineBox could sense whether log noise would be useful in other contexts--e.g., as a metric that can be graphed. Or whether your logging is lacking something that might be useful, or just lacking signal at all (hey, user, your logs are just noise!).
I mean, I guess it's the best thing if you want to wreak havoc and chaos? Which, perhaps, you do!
Your suggested dichotomy is, of course, a little bit false. But I'm sure you knew that when you wrote it down.
It's entirely possible to write secure programs in C, even with standard functions. Writing your own code does not somehow confer a level of security-consciousness that you lacked when sticking to strings.h. (It does give you a wonderful opportunity to write your own security holes that no one has discovered yet!)
I mentioned this somewhere else, but we're in a pretty good place right now with languages; we finally have really solid alternatives to C that can compile to machine code, in both Go and Rust.
The main issue is that there's already a lot of standard library support for classical strings--things that are just a pointer to a chunk of bytes, and no more; rewriting those functions would be destructive. The C standards group could add to the standard library, I suppose, but generally they are a bit reticent to do so.
It is not the case that C has a benevolent dictator with a particular vision and drive for the language. It's more like a small group of people who don't want to mess things up. And so not much changes. This is neither good nor bad to me--it simply is; and anyway, these days, you have quite a few options that do offer automatic strings that can also compile into machine code (Go, Rust I suppose?).
I highly recommend the Static Analyzer that clang already uses. I use this frequently in the C project I am currently working on, and it's very good at spotting memory leaks and other potential issues. I've had more than one occasion where I've looked at an issue it's reported and said, nah, this is a false positive...oh, no, wait.
Ah-ha, well! There are actually two Apple IIe models. (Well, there was a third "platinum" one too, but let's not talk about that.) One would have shown "Apple ][" at boot time, and this was the original model with a 6502 NMOS-based chip. But they later released an "enhanced" model, which had a 65C02 CMOS chip. You could tell the difference because the later model would have instead shown "Apple //e" when booting.
It's quite possible (perhaps because you typed it as Apple //e!) that you were actually working with that 65C02 variant, and thus, your janky stuff was forgiven by the Gods of Early Personal Computing (blessed be).
My understanding is that in the 6502 (NMOS) chip, those other opcodes had undefined behavior, and you might crash if you executed one. So you'd need to know who was the manufacturer to be certain that opcode X was available.
In the CMOS version (65C02), illegal opcodes are treated similarly to NOPs--they don't crash, and don't do anything other than spend cycles--with the caveat that certain of these "illegal" opcodes have specific numbers of cycles and bytes that they consume which are different from other illegal opcodes. More confusingly, there is an actual proper NOP instruction (0xEA), which consumes the one opcode byte and two cycles, which exists in both the CMOS and NMOS version of the chip.
So some of the illegal opcodes are just like NOP, and eat one byte and two cycles; some eat two bytes, and 3 or more cycles; and there's at least one which not only eats 3 bytes, but eight (GASP!) cycles.
Source: if it's possible for one to consider MOS emulation a hobby, then let's say it's a hobby of mine.
JWTs are really not a good idea for session storage. I wouldn't consider them secure by any stretch. ElastiCache would be a much better option, and relatively straightforward to configure.
I suppose time will tell whether generics are added or not. I'm--not exactly buying your argument that Go's compiler is badly written, or itself the reason that generics can't be added. But god bless ya for having an opinion.
Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade.
If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages.
(Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.)
Huge caveat: This article was written in 2012. So do yourself and fellow reader a favor and not argue over content that is now six years-old.
Obviously, Go has not replaced C++ usage. And, these days, I would see Rust as the more likely step from C++.
(Although, I still feel that it remains to be seen whether Rust will make a huge dent there; is memory-safety the killer-app feature that makes people want to use Rust? Do enough people feel that they Need To Use Rust to make it stick? I'm interested to see how that plays out.)
What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land. Generics may not make a huge deal for you because there were no generics to use in those other languages. And Go is quite a bit faster than any of the aforementioned interpreted languages.
Expressiveness is not always a pure ideal; reducing your business logic to two lines of code comes with tradeoffs. The ways your code work within the frameworks you choose is not always obvious, and when something goes wrong, it's harder to point at one place within your two lines of code and say: this must be it.
The opposite is not, and should not, necessarily that you write your own versions of things; after all, if you did so, you'd still have as deep of a stack trace as you do with the third-party code!
I guess, if I encountered this stack trace, I might say there's something of a code smell there. But, hey--this is also fairly old code, and I suspect things are Better Now, so let's not be so quick to cast stones!
In my experience, the code you write within a third-party framework rarely works the way you expect it to the first time. So you often do "debug" the framework, just to see where your code goes while in the framework to see what you missed.
That's not a bad thing, though--it's a great way to learn any new framework!
To me, this essay read more like a troll; a mish-mash of complaints and anecdotes that don't frankly make any sense when put together. But the author succeeded in getting to the first page of HN, so–congrats?
As such, it's hard for me to bring myself to respond to any one point in the piece. It'd be quite easy for most of us to do so, but I suspect that was the intention.
I recall reading something from some of the language developers who had indicated that their worry with generics was whether they could do it right. I inferred that to mean, whether they could do it in a way that felt as simple as the rest of the language does.
I would guess generics, when it lands, would look syntactically similar to the way channel type declarations look; you can have "chan int", so perhaps you would have "vector int". That feels the most intuitive and Go-ish to me. Channels require special syntax to work with, but with generics, I imagine you'd want to make use of interfaces.
I can see a bunch of ways of doing it—but none I could guarantee would end up in the finished product! But I do think generics land at some point. The unfortunate thing is there's a sense going around that Go doesn't have generics because the language authors somehow know better than everyone else; if anything, I think they have an abundance of caution that some other language developers have lacked.
Can you explain a bit more about how you became interested in assembly and programming the Apple II? And specifically, why you want to start the journey towards programming there?