True, but this may lead to some surprising results if you try to use the function more than once.

This part of linting is type-checking - it's just checking based on inferred types, as opposed to declared types. And it's fairly limited accordingly. My experience is that the larger the code base, the more useful types become relative to tests. What happens is that the number of meaningful states grows exponentially with code size. Since types are proofs, type checking tests more scenarios automatically as the code complexity grows. Hand-written tests generally test a fixed number of scenarios and this means if your test scenarios grow linearly with the code base, your effective test coverage gets worse as the system grows more complex. The other issue is that in larger systems, the cost of your test infrastructure becomes substantial because you have to run all tests that may potentially be affected (this is if you're lucky and can determine these things - most places either run all tests or tests that happen to be in the same repo/component/app/system). This doesn't mean tests are unimportant or bad but more that being able to rule out a large class of errors with types has substantial benefits.

Also, every large code base in dynamically typed languages is littered with errors that would be caught if there were types. This is the experience of every team I've heard of that adopted type-checking tools for JS. This becomes more obvious if you consider bugs in programs written in statically typed languages with dynamic features. Null pointer exception in Java, for instance, is a type error that would be prevented in a language that encodes nullability/optionality in types.

ITT we discover currying

I'm with you. I'm on the record in this thread as being in favor of typed languages in large code bases. We moved to typescript for our web front end and while it has a few oddities I greatly approve. Not that I'm trying to rehash that debate, I wasn't really thinking of the question about testing as implying some kind of preference for or against typed languages.

I like the thai green currying the best.

Some of us call it closures.

For me the tricky part was realizing a function can return itself w/o executing itself. Never tried that before.

Right. If you define once as “once per line”. You have a stateful function either way. The line break can’t reset it unless you do something special like that empty function call at the end you added.

I'm not sure if I'm misunderstanding you or you're wrong. Caveat: it's my wife's birthday and I'm well into some champagne.

But at the risk of being wrong and or just unnecessarily pedantic, it's not a line break that matters, it's the fact that the way I did it returns a new function for each call, so that you have different objects (functions) with values attached to them. I think this is fairly common for this kind of currying, and you can think of the mult method as a kind of factory.

So you can do things like

and be sure that they are entirely independent, so that mult12(2).value = 24, and mult96(3).value = 288, etc. They are still effectively pure functions in that sense, and you don't have to know anything about state to understand what they will return.

Yeah this is a much better approach than having a stateful function.

I knew a function could return itself, but I did not know that you can set arbitrary values on a function.

Oh yeah right, I got mixed up and thought your first solution (with .value, which is what I was given) was stateful too. Non-stateful is definitely better.

https://www.udemy.com/user/maximilia...ught_courses=1

Does anyone know what's going on with these udemy courses that have the price crossed out and listed at ~1/10th - but then when you click the course it's still the original price?

Shows the correct price for me when I add it to cart.

$11 or $149? Because I get $149. Are you logged in?

No, not logged in. That one actually shows 10.99 in my cart for 5 more hours.

Well, I powered through it and made a React app that is basically a copy of my non-javascript-based app. That's just step 1 though, I did this because I wanted a lot more interactive features so I need to do those too. The whole thing is ugly as **** and I'll have to address that at some point.

I think I might hate javascript. The lack of a standard library is awful. The fact that it's on purpose is unforgivable.

Like you're going to make me download an NPM library so I can format a number as a string? Great. Oh there's actually 20 libraries and they're all different and some of them won't work with react and some of them are essentially abandoned? **** you.

Rusty, maybe just a random example but for that there are built in functions:

https://developer.mozilla.org/en-US/...toLocaleString

https://developer.mozilla.org/en-US/...s/NumberFormat

That udemy course shows as £19.99 here with no crossed out stuff / "time limited offer" etc., which I'm sure used to be the norm. I also vaguely remember visiting pages at a later date would trigger some kind of extra discount.

That is really gross

Number.toString() WOWTHATWASHARDJAVASCRIPTSUCKS

I mean number formatting might not be the best example but I can understand why someone coming to javascript land from elsewhere might be alarmed by the way library management is done, just in terms of how overwhelming it can feel to decide which libraries you ought to use. Not so much because it's very difficult up front, but I look under node_modules and think about the recent eslint security issue and it's a bit scary. The chaos has its upside I'm sure, but also its downside. And there's so much variability in code quality.

The entire npm idea is stupid and was done stupid. That null is greater than or equal to zero but not greater than zero or equal to zero is stupid. Changing a number to a string is not stupid.

This does not even remotely do what I want

I ended up downloading a sprintf-a-like library.

since apparently I'm a little spicy today I'll just say your lack of understanding about something and/or your inability to communicate what you need does not mean something is necessarily bad, just that you have a ways to go.

How about since I'm also a little spicy I'll let you know that I think programmers who program in languages that include formatting functions as a built in feature of the language would know what I mean.

Programmers without such experience, but who are aware that I'm probably not an idiot might have taken 2 seconds to think about what they said before making the post you made about Number.toString.

New development in job search - 2 person female startup have now both reached out to me. If they offered me a job right after the interview I probably would have jumped on it. But they kinda ignored me for a few days, even though I reached out the next day. I figured they were a no. I wonder if their first choice fell through? Either that or they interviewed a few others and realized there aren't too many experienced devs who will bite on a job where you start with no in-house technology and could be just cobbling together 3rd party stuff as a 3 person company for a year.

Now I might have a tough decision if they and the streaming co. offer a job. Bit of a roller coaster from my worst performance ever as a programmer on Wednesday, and wondering if I'm too old for this ****. I'm sure they're still laughing about me at that place.

I also have an onsite tomorrow with a company that collects rent for multi-unit apartment buildings. SEXY! But I did click with them even though talking to the guy two weeks ago feels like a lifetime. At least I should be more relaxed because I'm not sure if I even want the job. Gotta work to not come off as cocky though.

I went hiking today, which is always good for thinking, and decided if I don't get a job in this round I'm gonna go into a cave, collect unemployment, and make my AWS/react/whatever else app. I know what I want to build and I was kinda looking forward to it.

I also realized that no matter what job I take, next time I quit to travel for 6 months - I better be completely up to speed in all the hottest full stack technology - one way or another - take a side job, build my own thing, etc. I'll be in my 50s trying to get hired so I better have every possible leg up. (I don't look near 50 and I don't give my age or graduation date anywhere - but I always wonder what they can find out.)

The big thing I'm trying to figure out is how much farther I'd be willing to drive, or work in a crappier situation - for $10k or $20k more. My instinct is to not care so much. But then I think that's $500 to $1000 more a month after taxes. Would you all drive an extra 45 min to an hour per day for $10k more? Would you work in a less sexy technology for $10k more? $20k?

I'd definitely work with less sexy tech for that amount of money. I wouldn't take the extra commute though. That **** is soul sucking and really wears on you fast. Plus you can kiss $200/mo goodbye just on extra gas for that commute