21–30 of 59 posts
Reminds me of this sweet paper http://research.microsoft.com/en-us/um/people/nick/coqasm.pd...
https://www.cs.cornell.edu/talc/
And Vx86 used in Microsoft hypervisor:
http://swt.informatik.uni-freiburg.de/staff/maus/dissemain.p...
Note: Microsoft also used a TAL, though can't recall if same as Cornell, in their VerveOS that was verified down to assembler. Combined with SLAM, it's safe to say their researchers are kicking serious behind on practical, cutting-edge verification. I wouldn't have believed it 10+ years ago if someone told me haha.
Earlier quoted context omitted.
Well, a creative abuse of the language. Programmer humor.
Being a developer myself, I'm well aware of this. Still, it's ugly.
This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this. Remember "Diesel", the Rust compiler for SQL, from a few days ago? Just because you can doesn't mean you should. Too much fancy template stuff is being baked into the low level libraries. This may not end well.
C++ went down this road. The template system turned out to be more powerful than intended. Then people started writing cool stuff as fancy templates. Then the C++ committee added features to support the fancy templates better. Overly elaborate templates damaged C++; nobody could figure out what was going on. Use of C++ for new work declined.
All of this comes from smart people with good intentions. But when there's too much of this stuff, the mental load required to keep up with all of it becomes excessive. Especially if it changes a lot.
Earlier quoted context omitted.
Being a developer myself, I'm well aware of this. Still, it's ugly.
When I see this, I understand why the Go crowd didn't put generics or macros in Go. It's so easy to write useful but awful things with them, and they're really hard to fix and debug. This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this. Remember "Diesel", the Rust compiler for SQL, from a few days ago? Just because you can doesn't mean you should. Too…
Rust generics are deliberately less expressive than C++ templates, in that they're strongly typed. That's why we get so many complaints from C++ and D developers that you can't do certain things. But Rust sticks with its strongly-typed generics, because Rust has always tried hard to strike a balance between code expressivity and maintainability.
This is a terrible example if you want to prove that point, anyway. This 6502 assembler is obviously a total abuse of the system, and nobody will deploy it to production. It's a neat hack, and that's all. Nobody would use an obfuscated quine written in Go to argue that Go is unreadable. This is exactly analogous.
Finally, Diesel is just an ORM. It uses exactly enough features to be an ORM; the only "problem" with it is that it's an ORM.
It doesn't support explicit accumulator addressing mode (ASL A, LSR A, ROL A, ROR A), but otherwise quite neat. (from a quick look at it) (also, 0x syntax is quite unusual, but I assume $ couldn't have been implemented for some reason)
The accumulator is the only register those work with. It was very common to not specify it.at all. I actually never have in all the 6502 assembly code I've ever written. Wasn't required.
http://www.downloads.reactivemicro.com/Public/Users/David_Cr...
Code is straight from the Red Book listings. Search for ROR - accumulator (shown explicitly), indexed, you name it. 4 modes each.
Earlier quoted context omitted.
When I see this, I understand why the Go crowd didn't put generics or macros in Go. It's so easy to write useful but awful things with them, and they're really hard to fix and debug. This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this. Remember "Diesel", the Rust compiler for SQL, from a few days ago? Just because you can doesn't mean you should. Too…
This is silly. Rust could not achieve its performance and safety goals without macros and generics. Generics may have been optional for Go (I don't agree, but let's go with it), but there is no way to achieve zero-cost memory safety without generics (while supporting first-class references and dynamic allocation). Rust generics are deliberately less expressive than C++ templates, in that they're strongly typed. That'…
In C++, you get this damage from for example operator overload abuse (ok for math, not many other defensible uses), template abuse (ok in moderation), ninja exceptions and inheritance (especially multiple inheritance, ugh).
Anyways, if Rust proves to be a feasible workhorse building medium/large systems with bigger teams, it does sound interesting to me. Especially catching concurrency issues at compile time.
I just hope it won't ever become another C++.
That ... is ... f *ing ... ugly to look at.
Earlier quoted context omitted.
Being a developer myself, I'm well aware of this. Still, it's ugly.
When I see this, I understand why the Go crowd didn't put generics or macros in Go. It's so easy to write useful but awful things with them, and they're really hard to fix and debug. This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this. Remember "Diesel", the Rust compiler for SQL, from a few days ago? Just because you can doesn't mean you should. Too…
And it is even easier to write useful, beautiful things with macros, which are really easy to fix and debug.
It doesn't support explicit accumulator addressing mode (ASL A, LSR A, ROL A, ROR A), but otherwise quite neat. (from a quick look at it) (also, 0x syntax is quite unusual, but I assume $ couldn't have been implemented for some reason)
Isn't A the only register those ops can use anyways? Although it's been a while, 25 years...