1,004 karma · joined November 21, 2016
EDIT: Okay, so I looked up what {'k'} means, i.e. it's an array with one element 'k'. And in the article's function it's the "path" to the key to be set.
Still not sure if ARRAY['k'] is a thing, though. I could only find this sort of syntax described in the context of definition, e.g. ARRAY[4] for an array of length 4.
The argument is rather that the AppStore is not secure at all, but a) we still cannot sideload apps and b) legitimate apps get kicked off for no good reason, etc.
The problem is false security and false expectations.
Arguably it's easier for a user today to accidentally download a scammy app from the app store than it would ever be to do when sideloading. The latter would always come with the expectation and warning that it's not vetted by anyone, so the user and/or community will invest the time to make sure the download is legitimate.
In fact YOU (well, I mean Apple) cannot have it both (other) ways. It's not fair to arbitrarily remove legitimate apps, lock down the devices, under the guise of user safety but in the end fail to actually provide the level of security at all that people now expect and paid the price of the device not being GP.
If Apple is so sure of their measures they should also cover (i.e. pay up) any damages when fraudulent or dangerous apps do make it to the store or are not removed in a timely fashion. The fees they siphon off from app revenue should probably go there.
I was just put off from doing so because of the author's assumption that everyone in tech is on the same page when this isn't necessarily the case. Many or even most folks "in tech" give little thought to PL design, at least not in the way that would have them read that article, though influential it might have been to some folks in tech that are into these discussions 6 years ago.
We are?
Ultimately limiting interpreters to AST interpreters is not quite correct. The AST is just another IR that source code needs to be converted to just like bytecode. And the AST is essentially also executed by a virtual machine. Interpretation of the IR (the AST, or bytecode, etc.) is one part of a VM. Of course in some instances the VMness of a runtime is more pronounced (Java) than in others (Ruby).
The difference between interpretation and compilation is that the latter is meant to run on real hardware vs. the former implies something that executes the IR of a program by dynamically choosing which machine instructions to run.
Of course a compiler is also something that takes in some code and outputs some other, typically more low level representation.
My point being I don't think there is a strict or consistent definition these days for what an interpreter is.
Case in point: I've also heard people say interpreters read the code "line by line" (or rather, not that but more accurately, as far as they need to read before they know what to execute next) and execute it piece by piece. Which might be how some interpreters worked in some languages in the past. An AST interpreter OTOH already implies some whole source file pre-processing. Is an AST interpreter then less of an interpreter than one that streams the source code line by line. Is a program that does that more an interpreter than another which goes a step further and, e.g. executes a simplified AST, or one that executes a straightforward trivial bytecode representation of the simplified AST?
- since Festivus 201X
> In a closed world, these [two different ways, data vs. object, to represent two different instances of coordinates on which the same interface (in name and signature) is defined] are identical representations [of a data type bundled with a single method/function].
They are saying that the example in Java and the example in Haskell have the same expressive power. Both allow you to apply a distance function / method to a Coord type coord "thing", and depending on whether coord is a cartesian coordinate the cartesian coordinate based distance implementation is used and if it is a polar coordinate the polar coordinate implementation is used.
Now, it would have been good for the author to acknowledge your point as well so as to avoid this misunderstanding. After all in the example, there is an underlying aspect / layer of things that can be substituted. I just don't think the author intended to talk at all about the actual (non) equivalence of polar vs. cartesian coordinate representations here. They'd probably say (and I'd agree) it doesn't matter at all for what is discussed. You could add a disclaimer saying "these coordinate types are both not actually equivalent" and it would not actually affect the validity of the points made.
P.S. It's not even that the example is bad either. After all it's not uncommon in real codebases that two actual implementations of the same interface are producing subtly different results (e.g. calling into database engine A vs. B). Often these differences don't matter and the benefit of being able to exchange implementation / internal representation lies elsewhere (see DI).
Actually, I might have jumped to a wrong conclusion. I really don't know if that's what happens here, but if not then it would imply that recursion isn't actually driven by the evaluation mechanism, but by Logica creating enough tables for a given program to ensure that iterative evaluation of rules ends up with a fixed point result set. Not quite sure. None of the other examples show recursion in the SQL output itself either.
Well, at any rate I'd like to learn more about the actual mechanism here but they are a bit light on documentation.
Logica instead seems to create tables and drop tables?
https://github.com/EvgSkv/logica/blob/main/examples/Logica_e...
It looks like Logica code isn't actually translated to a (large) SQL query, but Logica code is dynamically interpreted by some interpreter that calls into a SQL database as the virtual machine.
Not sure what Logica really provides here. Datalog usually comes with elaborate techniques to make sure only what's really needed is calculated instead of just generating all values every fact generation "iteration".
At work the other day I saw someone use a similar pattern in Java 8, where they had huge (think 250 fields) nested DAOs meant to construct JSON for some odd external API using a method called wiz, e.g. (not actual example):
new Payment().wiz(p -> {
p.amount = 100;
p.currency = Currency.AUD;
p.method = new Payment.Method().wiz(m -> {
m.type = Type.CARD;
m.reference = "2323232...";
}):
});
new Payment() {{
amount = 100;
currency = Currency.AUD;
method = new Payment.Method() {{
type = Type.CARD;
reference = "2323232...";
}}:
}};
Aside from not necessarily linking to the outer class like double brace initialization, the lambda solution does have one advantage. It provide an easy way to construct an immutable variant. You "just" have to make a copy of the class with all fields final and .wiz() produces only the mutable versions.
People will probably say "just use builders" but I honestly don't think their boilerplate (for both writing and also using them) is worth it, i.e. it's not just as simple/easy as creating a mutable /immutable pair with exactly the same content, just different modifiers on fields.
Long story short, it's good that this with keyword addition is discussed, but I think before that it's important to allow simpler initial construction of records. AFAIK they don't offer a nice way to do so, just the nameless constructors based on argument order (with a max limit as well like any method).
Wikipedia says it's essentially a pure subset of Prolog, but Prolog is not classified as a functional language, so I'm curious what makes this one called a functional language.
I assume there must be some significant language features that e.g. functions.
I think the idea is that most people will start exploring the world of programming from higher layers working their way down. People use software, then they write software with tools (languages), then they try to understand the tools, then they try to understand what the output of the tools mean on a yet deeper level, going down the rabbit hole all the way down (to physics? but I guess the lines is drawn elsewhere).
This may be wrong but it's obvious from the rest of the matrix that this is probably just based on how the author and maybe their friends gained "proficiency".
None of this is generally applicable. I do think the,matrix is still valuable. It provides a view of how some people may evaluate competence (even if misguided wrt ordering/levelling) and provides a set of goals that are not bad per se. Being on the highest levels mentioned there does probably in fact translate to a certain high degree of experience and competence.
Quitting a job is similar. I think even outside Japan it can be awkward leaving a job if you feel in some way indebted to your company. Now imagine your boss shouting at you, or maybe worse, appealing to your obligations not to leave the company, convincing you how doing so would make you unworthy of being considered a decent person, or even threatening to give you bad references, etc.
Sometimes it's actually that the other party isn't even malicious and doesn't have to be as ugly as described above. They may truly believe it's in your best interest not to abandon something.
Many people give in when faced with back pressure in those situations or at least struggle with going through such a stressful situation, i.e. many people know they may not be strong enough to go through with it when facing confrontation, so is it a surprise that a service that acts on your behalf is something people would use?
Now add to that that in Japan people generally try to avoid confrontation (esp. those likely to suffer at the workplace / school) and then imagine maybe being in a company that bullied you for years and you've seen others struggle with mustering up the courage to leave. Also, as far as I know, job hopping is still not seen as good. Many people still hope to stay at the first company they got into for a long time, with parents and partners hoping the same (and often pushing back against job changes).
Children? No, it takes them up to middle school to get somewhat proficient with Kanji knowledge for daily life, but they can still not read a lot of Kanji at that point.
Trust me you can learn this too on the same time span and semi-full immersion if you started now.
I don't expect you to understand the app if you use it for the first time when drunk, but I feel like if you've used it sober before and they didn't just completely change the UI you should be able to grok it. Maybe not if you are completely dead drunk, but I'd say you'd have the same problem with other apps you don't have already internalized completely.
What apps do you think would not have confused you in your state at the time?
The way I see it mocks are the all encompassing tool here. With mocks you can both stub behaviors and, if you want, verify behaviors.
And in reality every mock needs to act as a stub, e.g. a mocked method returning a preset value. So, it seems natural that "mocking" as more encompassing concept is what is used in library names. If people end up using those to mostly create stubs instead of mocks so what?
My experience so far has been that people naturally flock to a solution for testing that is flexible and lets them quickly cover the boundaries of the code they are testing. If people want to check if their code calls a method x times but are not interested in what that method does for the test, they use mocks. If they do they use "the real thing" or a fake on which they can validate state later. And if they just need a method to return something and don't care about whether it's called or how often they use a stub.
I feel that often when you stub you can also go ahead and add code to verify some behaviors (mock) to get some extra coverage. I don't know I just don't think it's bad to mix and match if it gets you to more things tested.
You will always need to spend some time project managing your project even when things are not as process heavy.
You still need to make sure that timelines are met or flag if they are not. Keep dependencies informed, push/remind other teams you depend on to fix a bug, add the feature they promised. Communicate with management to get more resources, etc.
A PM can do all of those things with a bit of input once in a while from engineers.
These things only aren't important if you neither have timelines to meet, have no dependencies, and aren't accountable for the success of your project. Outside a hobby project outside work I'm not sure we ever have that luxury.
The article doesn't talk about other roles, so maybe where OP worked these things would have been assisted by other roles, e.g. the product manager. Maybe from that perspective it's not clear to the engineer what value project managers provide but I feel it's a bit of a limited perspective to say a role that can dedicate their time to tasks of type X isn't of benefit to those who'd otherwise need to do these tasks.
I mean would you say the same about customer support? About getting clarity on compliance/legal/finance (via asking external council)? About internal developer tooling? There's a point where an engineer working on a product may need to do all these things in addition to the building. But you cannot claim that it'd make no difference to the engineer's efficiency if they could delegate those things to others.
Where I work there's lately been so much additional process, planning, keeping stakeholders and dependencies up to date, etc.
Yet, the product manager position isn't really staffed, and neither is the project manager one. So, all the additional work beyond design and coding also falls on the owning engineer. And since we are frugal that engineer is happy to get maybe 1 additional engineer assigned to help. But often that one will also have their own project they own or need to prepare for owning.
So the lead/owning engineers turn into mostly product and project managers but are still expected to do the down to earth construction of the product which means to get anything done in the expected time frame engineers need to put in long hours.
I just don't get it. It seems utterly wasteful use of resources. I'm not saying engineers cannot be good at these things, but generally speaking product and project managers cannot and do not need to be able to code in addition to owning a project/product. Adding/hiring more project managers to projects would be the single most effective way to speed up project timelines as it frees the engineers, the producers of tangible product deliverables to focus on that.
In no way do I mean engineers should be cloistered away from dealing with product or project decisions or even chatting with users. But it needs to be in the correct proportion to the actual engineering work.
Add to that the addition of duplicate processes (e.g. we are dealing with 3 right now that cover the same ground but are ever slightly different in what needs to be done to cause triple effort) and everything grinds to a halt. A project manager could also be the right person to push back on management and dedicate resources to improving project management overall.
That theory doesn't make sense to me.
Because the headline you gave seems pretty close to what is in fact reported all the time.
I've worked with managers who only asked questions and let the team decide everything. The problem is that the team is generally already stretched really thin and isn't really free (in terms of workload) or equipped to make decisions. When the manager essentially delegates all of the ugly and messy work to the team (i.e. decision-making) I end up wondering what they're actually doing.
It's one thing to ask and field questions about what everyone thinks about a subject in order to make decisions (and maybe that's what you meant), but in my experience the second part rarely happens. Maybe it's just me, but I feel overwhelmed with being asked a bunch of questions when I actually desire concrete guidance or direction. Granted that's a case by case thing but I feel that managers who do the former aren't that good at the latter in times of need.
I don't think the fee is there to protect device health. There are plenty of free apps with no fees levied, so that point doesn't make sense.
I think it's fair to charge a fee for using the store as a paid app distribution channel. If Apple takes on the burden of risk, funds flow management, etc. it's fair to take a cut.
If Epic instead builds their own payment system, they shouldn't be charged for it or forced into using Apple's.
Apple could claim that they need to cover hosting costs or review costs. And I think there's an argument here, but it's not made, and it would raise additional questions around fairness.
Any level of a game contains at least some logic like NPC behaviors, event triggering etc. and I'm sure scripting is a standard component of every single game.
Have you heard of Thimbleweed Park? It's basically a VM executing an adventure game language (like the creator's SCUMM VM in the past).
That's on the App Store.
Now if we specifically look at the downloading part, that would mean games on iOS cannot download new levels, which I think is done by a lot of games.
I'm not in the US or talking about the US per se.
I as a customer want 3D Secure because I don't want to deal with fraud at all but AFAIK it's not that liked among users. And I did run into issues where the 2FA setup my bank offered took a physical letter to initialize/reset and I couldn't actually buy flight tickets I quickly needed (ended up changing cards). So I can sort of see how people can get a bit annoyed as long as 3D Secure is a bit frictionful.
Online businesses would like it if it helps them avoid fraud as well. The problem is that conversion rates drop and so only few businesses implement/enforce it unless it's the law (see EU). Given how simple it is for a customer to ask for a chargeback I don't think there's a clear winner here for using 3D Secure except for acquirers and brands. Issuers don't really gain anything either given their already strong position when handling chargebacks.