59 karma · joined November 17, 2018
Also, the likes of Haskell let you build binaries dependent only on OS provided libraries whereas the likes of Nim compile to C. You might want to play with the short listed languages to get an idea. A simple Hello World will tell you what they link with by default. Anything beyond that is up to you.
https://www.zdnet.com/article/two-malicious-python-libraries...
Ironic that this was published today. :-)
This. And to make matters worse, a lot of benchmarks start with something like, "To be fair to <the slower language>, let's cripple <the faster language> by implementing the programs using the paradigm favored by <the slower language>." If you want the real results, have an expert in each language implement the spec without looking at the other program.
Someone mentioned Photoshop being slow compared to Slack/VSCode. That is Apples to Oranges comparison if I ever saw one.
> And the disadvantage is that they are are huge, resource intensive and pathetically slow.
And don't work natively on any platform. You essentially program for the lowest common denominator and do not take advantage of any of the features provided by the platform -- especially accessibility. For example: Zoom In on any half-way decent editor increases the text size. Zoom In on VSCode (macOS) blows up the entire UI -- leaving little space for actual text. This is just one example -- I can line up many more.
In theory -- yes. But in practice, it is write once, debug anywhere. Remember a certain electron app consuming 100% CPU for a blinking cursor on a certain platform?
How do you count any of these editors — especially Sublime, Vim and Emacs — as featureless? If anything, Vim and Emacs are more fully featured than VSCode and Sublime Text not exactly far behind. I haven’t used the other two during the last few years, so can’t really comment on the state of plugin ecosystem for them.
C is essentially a portable assembler. It’s not enough to learn the language, you need to have deep understanding of the underlying hardware and compiler infrastructure.
Abstractions are invaluable if you are dealing with a large codebase. Even the original author can’t keep everything in their head.
Indirections are invaluable if you want to be able to modify code in the future without making a gigantic mess — and potentially breaking compatibility in the process.
“Abstractions — or rather, indirections — are bad for for readability, but they are good in some cases.”
Umm... this can be said for pretty much anything. Over use of anything is bad. Inappropriate use of anything is bad.
> Mostly, I want authors to be aware that there is a human cost to indirection that is felt more acutely by everyone reading the code except the original author.
Sure. It’s a well known fact that abstractions have associated costs — nothing new there. However, the author seems to forget that not abstracting things can be equally costly — even when human readability is concerned.
Imagine someone trying to figure our the business logic be reading code. All they need to know is some conditions are being met for certain steps to be executed. The actual steps involved in the check are irrelevant to the business logic. The condition can be modelled separately from the business logic and can even change independently. For example:
def is_foo_condition_satisfied((self):
return self.variable.startswith(‘foo’)
In this case, it just happens that the satisfaction of a condition is implemented as prefix check. In the future, it might be changed to checking a flag or reading a database, or anything really. If you sprinkle the startswith() check all over you code, it will be hard to make the change. And it actually hurts readability. While reading a large codebase, you want to focus on specific parts of it — getting into the details of everything all at once does not make it easier.The most important thing to note is — programming is not confined to s strict set of rules. It’s not an exact science. You can’t define a strict a rules that must be followed. What makes sense somewhere is completely useless elsewhere. The Linux Kernel is full of goto statements, despite the fact that goto is considered harmful.
Dogma Driven Programming must be avoided. Even well known programming practices are guidelines at best. One must evaluate whether a given rule fits a given situation.
Coming back to the example at hand, functions are meant to divide the program by the logical tasks being performed, not by number of lines or any other metric. As I said before, it’s more art than exact science.
Is the check for foolikeness of something a logically distinct task? It depends on the context. There is no way to write a cardinal rule either way.
PS. I sincerely hope no one comes to me for code review with a monolithic function because of all the inlining — citing this article as inspiration.
Edit: Typo correction.
(Please do not start a iOS vs Android battle over this comment -- this is simply my experience -- I use both on a daily basis -- your mileage may vary)
Don't get me wrong -- CarPlay/Android Auto are leagues ahead of what individual car makers have to offer. Having a standard system across all car makers is a good idea too. They just need to come up with a more tactile interface.
The touch screen doesn't necessarily have to go, though -- it could simply be disabled when the vehicle is moving.
Volkswagen, for example, have a rotary dial which lets you flip through all the items on the screen to select the one you like. It still requires the driver to glance at the screen, but at least it doesn't require them to touch the precise spot on the screen -- which IMO is more distracting. That said, even the rotary dial is not perfect as it can't be operated by touch only -- w/o taking your eyes off the road -- not unless you know the position of every single icon/control by heart.
What does any of this have to do with a GUI? And for transporting, extract the data into a portable bundle, or take the entire store.
> Is the application store the only way to start at app? If I bind a global hotkey to start an app how is that handled?
Again, what does any of this have to do with how the applications are stored? Can you see the files that make up an iOS app? You can still start them, can’t you? A macOS app is a folder called Something.app, the actual binary lies somewhere inside. Do you typically need to poke inside the .app folder?
> How about I have an addon for firefox that allows me to bind keys to operations which can include javascript which can itself start applications which can then write to files.
As far as the computer is concerned, you are merely starting a process. Again, what does that have to do with how applications are stored. They can be triggered however and wherever they are stored.
> Do I have to access my photos via a a singular photo manager? I can imagine images accessed in 17 different contexts by 30 different apps does each of them need permission to access each dir which contains images or just generically to access images
This is already being handled on iOS and Android. Photos apps is merely the default interface for the PhotoStore. You can access your photos from any app.
> Does this mean that a singular permission would control both access to the browsers cached image of the ycombinator logo on this page and some ones nude selfies?
Namespaces inside individual stores, or separate stores.