In another words friction slows movement down and does not treat some direction on surface more preferable than others. Assuming regular surface this is pretty much definition of friction.
I am not sure how well I have explained stuff but if you are able to experimentally disprove this it's worth of paper.
For some reason I cannot reply to your comment wizzwizz4.
We are talking about dynamic friction in it's simplest form. You can treat it as simple math problem too. Let's consider two extreme cases:
A: Side slip is 1m/s and wheel spin zero or very small.
B: Side slip is 1m/s and wheel spin extremely big, let's say 1000m/s.
I think we can agree that friction is always opposite to surface speed. If wheel spin is on x axis and side slip on y:
On A case friction is (0, 1).normalized() * friction-coefficiency => (0, friction-coefficiency)
On B case friction is (1000, 1).normalized() * friction-coefficiency => [approximately] (friction-coefficiency, 0)
On classroom teacher says that slip does not matter. What teacher actually means that slip does not effect into -magnitude- of friction but this is left behind because problem is presented in context of 1D. Tho in 1D slip still matters little bit because there is difference is slip 1m/s or -1m/s.
Sometimes I am wondering what if there is theory which have been on right track but it's (false?) falsified and already forgotten. Sure theory could be incomplete or incorrect on some ways but would that right part be noticed? For example I think it's too easy to imagine world where relativity or quantum theory would be socially falsified and/or left without any attention.
Simple example experience I had when I was beginning of my physic studies (which I never finished) was when discussed with elder/smarter student about wheel friction. I was explaining that I had figured out that wheel spin actually matters when there is also side slip. [Total slip direction is dependent from spin speed.] But because he -knew- that wheel spin does not matter and he -knew- that he was better/smarter/etc. he was so focused to correct my mistake I was unable to convince him. How much this happens on higher stakes?
So if situation is that there has not been much progress for a long time I think it could be valuable also understand these failed theories and of course very importantly why they are falsified.
When I am working with hard problem I usually go this order:
1. Describe the problem.
2. Describe bunch of naive solutions.
3. Describe problems in those naive solutions.
4. "Describe problems in those problems": Why some of those problems do not hold water. Those can be workarounded, fixed or they actually are not really problem in this case or maybe some combination of naive solution properties gives working solution.
At the time I was lost joy of coding too but I was able to found it again.
One key point was to ignore learning new tech if it was not absolutely necessary and focus just creating new things. I think it all started from Sebastian Lague's video which reminded how beautiful coding can be.
Excel does not support any delimeter natively since its region dependent.
I ended up saving my mental heath by supporting two different formats: "RFC csv" and "Excel csv". On excel you can for example use sep=# hint on beginning of file to get delimeter work consistently. Sep annotation obviously break parsing for every other csv parser but thats why there is other format.
Also there might be other reasons too to mess up with file to get it open correctly on excel. Like date formats or adding BOM to get it recognized as utf-8 etc. (Not quite sure was BOM case with excel or was it on some other software we used to work with )
One can start from typical UIs and start tinkering from there why it isn't good enough for programming.
Good first step is to notice that we dont have even static data objects. Still UIs are full of them (forms) but you cannot copy paste or store them as a whole, everything is ad-hoc.
Now imagine that every form could be handled like Unity scriptable object. And maybe something what prefab variants do: data inheritance.
You propably would want to reuse referenced definitions like domain and IP which are not email specific. But yes all of our JS could be much shorter if we used APL but most of us like readability :P
I kind of not get why TLD should be validated. Does it matter anymore than if sub domain is not registered of if IP is not reachable. I think valid as potentially deliverable and actually deliverable should be distincted (like well formed XML and schema validated XML).
Thats propably because you are looking inlined assembly of definition. If you name and reuse all the partial patterns it become much more clear. Though regex is cool obfuscation method.
I claim that it's possible to design cargo ships and planes to be driven by anyone with short training compareable to driving license.
It all comes down how much you want to invest for being as safe as possible from accidents. Cost of cargo ship or plane accident is very high and there is no valuable reasons(?) why everyone should be able to drive those vehicles. Therefore it makes sense that those vehicles are driven by professionals and are designed for professionals.
If your server has millions of users and it provide such value that down time is not an options, maintaining such server should be done by professionals and maintenance tools should be designed for professionals.
However thats not case for every server and cost of failing "empty" server is basicly zero (unlike empty cargo plane).
I think it would be interesting to see software designed around not centralized servers, not PCs, but PSs = Personal Servers where user data lives on their own servers and services only link and communicate between them.
Why so? In web world we represent most of our non-UI structural data in JSON. HTML is also structural data but what makes it so special that serialization format is needed? Or why won't we represent any abstract business data as HTML even if it would have similiar structure?
Therefore I think it's very understandable why people come to that conclusion so often.
> To all the people complaining that modern web browsers are too complicated for small teams to build and maintain, do you think WASM helped with that at all?
Kind of yes.
For simple browser as a general application platform you need a simple base technology where much can be shipped as library level. It would be fun to see WASM only browser with JS and CSS layouting solutions run as WASM compiled libraries.
So in theory WASM could be used as a first step to more simple browser but in practise it's propably just a fantasy.
First: Yes null VS option type is all about static knowledge so it's pretty irrelevant topic in context of dynamic language. In my mind in such languages null propagation operator is basicly all you need.
But cmoon it's not about FP. Checkout C# value types nullable<T> for example. C# 8 brings same principles to reference types (however being non-safe since you cannot break compatibility). Only good reasons to have (Java like) null is to either because you already did it and you cannot take away or you are in ecosystem where it's fundamentally in.
And to be precise it's not about null per se. Null can be just fine but it shouldn't be valid value for every type. You can solve it either by boxing (traditional option type) or some Type Scripty flat: Car | null ideology.
In some sense all languages with Java like null have some option types buuut they are missing regular non-nullable types.
Because knowing which data is hidden by UI from server is hard problem.
To achieve real-time feeling game apply (most) your inputs immediately without having to wait relatively long time confirmation from server. So if you decide to push button and peek around corner you expect to see enemy immediately but server will know about your peek "much" later.
You can for sure limit some information by locations but you always must leak more than it's actually seen by client. Also it isn't easy to solve: can any part of volume be seen from another volume inside arbitrary 3D environment. Enemy size and movement through network frame => players all possible eye positions.
I think current best solutions rely on very rough (manual?) map piecing. So is it worth to invest for such thing that makes some cheats bit less powerful but cannot really prevent them.
Don't have experience about stack oriented languages nor sure is this relevant reply.
But to clarify: local mutable variables are fine because effect of changing value is clear due well specified scope. Mutation is not observable from outside of a function.
Opposite is true for using mutable data structures (with immutable variables): scope of effect must be checked manually, it's easy to leak function abstraction and with 3rd party code all the bets are off.