Risord

Btw this potential false falsify also popped up newest Sabine's video: https://youtu.be/NHrL4fkyWKI?si=nCuagTnP3WJIDbSv

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.

[https://youtu.be/X-iSQQgOd1A?si=aqriiWmcqqphOiuI]

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.

I think quite interesting starting point is general purpose visual medium which is good enough to be used for programming, too.

Aka: more visual/structured medium to some use cases we use text today.

TLDR: Monorepos have no issues in "real world".

(= My bubble, I am quite sure I haven't ever even met person face to face who have been in project of even 100 devs.)

Yea I don’t care neither but business seems to care. If you listen closely their specs are pretty much bloated with DUs.

Question as title is linkbait.

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.

Indeed semantics is what matter but I think for example lack of composability is semantic problem too.

<snarky> Ability to manage persistency and correctness of SQL engines is very usefull while language interface not so much. </snarky>

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.

I like pragmatic definition of FP by Eric Normand: We recognize separation between data, calculations (pure functions) and actions (impure stuff) while using always simplest category.

To me it seems like especially juniors would get benefit from this separations. So is it more like: "this language makes you do the thing that experienced programmers do once a while and juniors avoid [purity] at all costs". It would be interesting to see how juniors would work with functional(-first) language. Would they be able to craft same not-even-god-knows-what-it-does piece of art? What I have seen so far lot of side effects is typically required.

I don't either consider living without local mutable variables and loops as a clear improvement. But I do think that designing your application such way that it won't rely (or rely as little as possible) on spooky actions at a distance is.

Unlike Elm, F# is 'functional first' but supports OO and impurity (with good and bad).

Biggest clear plus is maybe full stack development support. Checkout SAFE stack (Saturn + Azure + Fable + Elmish).

There is also Bolero, an alternative for Fable how to run F# in client side. Where Fable compiles F# to JS, Bolero relies on Microsoft Blazor project which has a whole .Net runtime on WebAssembly allowing to run .net binaries directly on browser. I think this is still quite experimental but if you need/want some dependencies from .net ecosystem it might be easier than you think.

And what if you are used dynamically typed language for years and still cannot understand why anyone would choose on if can chose freely?

Seriously I have noticed that static vs dynammic preference is quite sustainable thing for people. Even if you are have used lot of both most people prefer the one they are used when they 'got it' during their programming learning path.

I don't really understand that CSV example what's the problem but one concrete challenge I have noticed with static types is when you want do mutation which effectively change the type. Instead of setting just new property you have to potentially do dummy copy (including type) or some additional hashmap by id for this additional data.

(btw I am not your down voter)

This case makes me wonder what if traditional filesystems would not separate files and directories. So that there would be just files which may have data and sub files. Then html file could include all js files etc. directly inside it so that we could give multi file permissions without leaking it to siblings.

Code smell #1/#2: If you have too long function/method break it apart. How does this relate code being in function VS method

Code smell #3/#4: If you don't want to put helpers to global scope then just don't. I don't see why closures are so bad. Top level function can act pretty much same as class scope so what's the difference? I don't know about python but if you really don't want to use closure another languages have other encapsulation methods too.

Code smell #5: If you use closure you can have shared state. Passing state can be noise but on the other hand if you only read/write "semi global" variables it's messy too. If you need to pass lot amount of state it's usually hint that you have some other problem in your code.

1. Like said you don't need objects

2. Function have single entry without ambiguity like @Someone shows.

3. You should test behavior, not specific implementation. You don't need mocking for pure functions.

4. Is X optional? What about Y? Does order matter when calling 'withs'? And that builder thing is directly stolen from all the Java jokes.

5. I don't know what is Pythonish way to do delayed callability but I claim that it should be independent thing rather than directly bounded to specific function/object.

If it looks like a function, swims like a function, and quacks like a function, then it probably is a function.

I feel your pain although I haven't ever implemented type provider to be precise. You have no reason to feel guilty! It's out and it's runs without any major bugs(!). Hopefully community will carry it and at very least it's one nice show case for compile time computing of F# (and maybe add motivation to develop that side of language further).

Great work. I used rezoom in couple of minor projects and like most that I could really trust that query runs if it compiles. Unlike in Entity Framework where you have unlimited possiblities write code which compiles just fine but crash runtime. In principle I don't like an idea that your primary language get compiled to SQL due it's very leaky abstraction. Instead I like expressing queries as data (ideally compile time checked).

In rezoom query composition part wasn't the strongest part. When for example some model needed additional join you had to modify N queries. This kind of composition could be done of course with dynamics but like you say, you lose biggest selling point: compile-time safety.

However these compositions are usually all known at compile time so you should be able to just build them before rezoom checks them. But out of the box compile time programming in F# is not there yet...

If soft delete is ok there is no problem. But should it be part of protocol or application layer is another question.

Managing universal data removal is not universally solved (or even wanted) on internet scale. So it sounds weird to demand it from technology which is trying to solve completely different problem.