In the readme there are only commands explicitly running the tool. Can it be set as the diff tool for git? If not, you should look into that. It will help adoption. And if yes, you should make it clear in the docs.
If you removed the explicit declaration of every gate in a preamble and then their wiring as a separate step, you could reduce the boilerplate a lot. This example could look like this:
component FullAdder(A, B, Cin) -> (Sum, Cout)
{
A XOR B -> AxB
A AND B -> AB
AxB XOR Cin -> S
(AxB AND Cin) OR AB -> C
Sum: S
Cout: C
}
BTW thanks for Daino! I'm working on assembling a set of tools to easily build and manage a personal knowledge base locally. I was worried I would have to build every piece myself, specially for note taking, so I was really glad to find Daino!
Oh that's awesome to hear! I have been playing with the idea of creating a desktop environment. Don't know if necessarily using i3wm but it's good to have your library if I do (:
> Stanza provides an optional type system, garbage collection, and a multimethod based object system. But if you don't like Stanza's object system, there is no way to write your own. This is one of the main directions of programming language research. Can we design a language so expressive that library writers can easily write the most appropriate object system, or most appropriate type system, to fit their application? Perhaps one day we'll have such a language.
We already have it. It's an obscure little language called C++. Tise interested in those kinds of extensions to a language should look into Herb Sutter's experiments with cppfront: https://hsutter.github.io/cppfront/welcome/overview/
Lisp is what you are after if you want to include some object system as a library, or a new type of switch statement as a library or a new kind of if statement as a library.
C++ can do some of that. Let's say I want an if statement that takes an integer and three blocks of code. It executes the first block if the integer is less than zero, the second if it is zero, and the third if it is positive.
OK, if you squint enough that by "block of code" you mean closure, or function object, then I can write that in C++. I can make the if statement a free-standing function (that is, not a member of a class), and add it to any library I wish.
Now, you can say that it's going to be tedious to use that, because you have to set up three closures every time you want to call this "super if". And you'd be right, but that's a different argument.
One problem is that closures don't actually behave like blocks. Consider that you might want to use this three-legged-if inside a loop. If it's a real statement, then those branches can have `break;` and `continue;` statements which affect the surrounding loop. If those branches are just closures being passed to a function, then they can't.
> OK, if you squint enough that by "block of code" you mean closure, or function object,
But we aren't squinting here; those closures can't perform a return where your `new-if` function is being used, they can't perform a `return` like a proper `if` can, you can't goto, or break or continue.
It's just a function taking functions, with all the restrictions that that entails.
Yes, a function call. Not new syntax. But as a function, it would be trivial to add to a library.
My point was that you can often get the effect you want with no new syntax. (Cue 10,000 replies that state "but you can't get this effect without new syntax!" Perhaps not. Many of those tend to be rather contrived, though. I'm more sympathetic to the argument that new syntax would make something less clumsy. If it's something you need to do a lot, that matters.)
Yes - I see what you mean. There are degrees of ease of use at between - at the extremes - what writing assembly provides, which technically can do it too, and what something like, say, Haskell provides. C++ is of course closer to Haskell than Assembly, but there's still quite a headache in using your solution that is down to absent C++ language features.
You can always use macros! Just look at how beautiful and elegant and easy to learn and transparent to debug the Microsoft C++ MFC COM/OLE/IDispatch/ActiveX object system macrology is. /s
The two fields in the struct are expected to be false unless changed, then initialize them as such. Nothing is gained by leaving it to the compiler, and a lot is lost.
I think the point is that sometimes variables are defined by the language spec as initialized to zero, and sometimes they aren't.
Perhaps what you mean is, "Nothing is to be gained by relying on the language spec to initialize things to zero, and a lot is lost"; I'd agree with that.
Not trying to be pedantic. When I hear "leave it to the compiler", I normally think, "let the compiler optimize it, rather than optimizing it yourself". The compiler is doing the initialization either way, but in one case you're relying on a correct understanding of minutiae of the language spec (both for you and all future readers and writers of the code), in another case you're explicitly instructing the compiler to initialize it to zero.
Yes and I'm saying that in this case the correct and practical choice is to be explicit. No one needs to go read the standard to know that two fields defaulted to false in the strict definition are defaulted to false...
Compilers implement the parts of the standard they agree with, in the way they think is best. They also implement it in the way they understand the standardese.
Read a complex enough project that's meant to be used across compiler venrdos and versions, and you'll find plenty of instances where they're working around the compiler not implementing the standard.
Also, if you attended the standards committee, you would hear plenty of complaints from compiler vendors that certain things are implementable. Sometimes the committee listens and makes changes, other times they put their fingers in their ears and ignore reality.
There are also plenty of places where the standard lets the compiler make it's own decision (implementation defined behavior). You need to know what your compiler vendor(s) chose to do.
tl;dr: With a standard as complex as C++'s, the compilers very much do not just "implement the standard". Sometimes you can get away with pretending that, but others very much not.
The standard (to the extent that it is implemented) is implemented by compilers.
At this point this whole thread has nothing to do with my original point, just weird one-upping all around
This was my experience, too. A Skeleton Key To Finnegan's Wake by Joseph Campbell helped me understand the overall themes of the book, and hearing Joyce read it helped me appreciate the language and the rhythm of the words. I found it more approachable once I saw it as a story told in wild poetic dream sequence imagery.
The only thing I know about it is that the book is supposedly the inspiration for the naming of the quark. I feel as if this satisfies any obligation I have regarding it.
It's been sitting on my shelf for a few years now. I take it out and read a couple of pages each time and then put it back. Keep thinking I should buy a guide to reading this book but never got around to it.
Even a short summary of the Wake can suffice to get you started. You're never going to understand it all, and that's okay, but even a brief chat with a Wake fan can give you the basic clues of its structure and the HCE/ALP Shem/Shaun dualities. I think it's a mistake to spend time with guidebooks than with the text itself if you want to read it for pleasure as opposed to writing a thesis on it. At least, postpone the guides until after your first trip once around.
You might consider visiting Dublin on the week of June 16th and partake in the readings and pub crawls... though there are other Bloomsday commemoration events. That said, the only time I've stumbled across this was trying to find a seat in an Irish pub in the early '00s and being confused as to why it was that busy that night.
Qbs is deprecated. Building with qmake is still supported for end users of the Qt framework. For building Qt itself, since Qt6, the build system was moved to CMake.
> “Fake it until you make it” is often dismissed as shallow, but it’s closer to Franklin’s truth. Faking it long enough is making it. The repetition of behavior, not the sincerity of belief, is what shapes character. You become the kind of person who does the things you repeatedly do.
Then you become the kind of person who fakes things?
I have read it in the past as a way to deal with imposter syndrome. You push past it by believing that you're tricking the system by faking it despite your own perceived inadequacy, when in fact you are performing perfectly fine. You do this until the results of your work are evident enough to ward off imposter syndrome. If you are indeed doing bad fake work then I guess this would fall apart, yes.
Exactly, and it has the potential to really burn others as well as yourself, when they do their work/job on top of what you claimed you had. I am not a fan of the "fake it til you make it" approach.
reply