352 karma · joined February 22, 2013
With that said, I do find it useful to write unit tests in Swift, just to see that the Swift API looks as expected. So that’s one way to add examples.
I use Discord and like it, but it is incredibly slow at starting, switching rooms, and even just loading new messages.
But the most aggravating thing is that I can't type a message on mobile if I don't have internet connection. It requires connection to load the input field. Affects me every day in elevators. Most native apps just lets you write your message and sends it when connection is back.
Fine, Discord is useful, but I must respectfully disagree that their app is good. And it is definitely possible to make natively.
- The operating system cannot share memory between different Electron processes. Normally if you start many processes of the same binary, the memory is shared and only copied on write. Since each Electron app is a different binary (even though they are 99% identical) they each eat memory.
- The above applies to disk size as well. Electron apps are usually huge, and 99% of the binary is the same as all your other electron apps.
This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. Now it's only updated if the developers decide to ship a new version.
Adding custom CSS/JS to Fastmate would be pretty simple, I might just do that as well.
Is there anything that you miss in your fluidapp setup that could be added to Fastmate perhaps? Thanks!
That would be solved if you had one Electron binary that started each app, much like a JVM. They would still be different processes so one app couldn't bring down another, but at least they would share memory pages and copy on write which would make the multi-electron-app world better. (IMO)
It would also have the benefit that you could update once and not run an old chat app with old Chrome security issues, until each developer decides to update Electron. But I guess the argument against that is that it's no longer "truly cross platform" since an Electron app may have to support multiple Electron versions. This is how things always have been though, developers just seem a lot more lazy about it nowadays.
(hello world)
That’s a list containing two symbols. So it’s data. However, if I evaluate that list, it will call the function “hello” with the argument “world”. So it’s also code.Incidentally, lists and function calls are identical in lisp, hence code is data.
I think the article just complicates it by introducing macros.
Examples include:
- totally oblivious to standard library for the language/frameworks, reimplementing the most basic things (poorly)
- even after a 3 year CS education, lacks basic understanding of object-oriented programming/class hierarchies
- has trouble implementing even simple if/else-conditions without help
I’m talking really basic stuff here. You’d be surprised. I assume that if you are self-taught, you have the interest and because of that already much more knowledge than many graduates.
I still have no idea how to do “correct” perspectives. This is just something I hacked together until it looked good.
I can very much recommend doing a project like this. You will naturally figure out how 3D graphics work, and it’s simpler than it appears.
It’s just annoying to have to remove every unused variable/parameter when trying changes out.
And don’t worry, if the new idea I’m trying is worth it, I will fix it up so it doesn’t have any warnings. And I saved a lot of time by not fixing all these warnings on the previous 2 ideas I tried.