bernawil

It's not because of "weak types" since the types inside the array don't get their type information erased. It's because Array.sort takes a comparison function but the default function instead of being something like

  [1, 10, 2].sort((a,b) => a > b ? 1 : -1)
  // -> [1, 2, 10]

is something like

  // [1, 10, 2].sort((a,b) => a.toString() > b.toString() ? 1 : -1)
  // -> [1, 10, 2]

because someone thought that it was "best" to cast stuff to string in case whatever you put in the container didn't implement comparison.

Isn't it kind of a useless distinction? I mean it's not like there are so many periods of pre-gunpowder history. We have ancient, medieval and that's it -you could add bronze age but we have so much less records-.

The whole "battles were rare, sieges where common" is a trope I believe some YouTubers started, but I don't think there's any solid pattern. Ancient armies pillaged the countryside to provoke encounters. Steppe peoples did pitched battles all the time because they didn't build walls. Medieval Europe may have had more sieges than battles because of religious homogeneity, but you can see how that model falls down soon in the thirty years war: if you don't engage the enemy they'll loot and pillage you to oblivion. Your people see how you are unable to protect them and desert you.

in a strict language? I don't think it's possible. Because if you take a better look you'll see that it's not enough to mark functions as sync or async since inside the functions each line of code can be considered a synchronous function in it's own.

What you want is something like Haskell that's lazy and its not about "executing statements" but rather "evaluting expressions".

>Whats a good language that shows off the style you're suggesting? javascript.

What you describe sounds like native UI work since forever before javascript. "Don't block the main thread" and all that.

Javascript is diferent in that it's a single-thread with an event loop. Synchronous functions execute until they end. Asynchronous functions are handled by the event loop which "loops" between the pool and runs each one for some time, then switches to other, concurrenly (think round robin). What happens when the runtime is running an asynchronous function and inside it reaches a synchronous one? it stops round-robin and executes this function until it ends.

What OP wants is a language like javascript but without having to write code distinguishing synchronous and asynchronous functions and instead having some other tool to tell the runtime when a function is synchronous or asynchronous without having to write it again.

But you realize that "it needs to outlive the current scope" is vague enough to support the statement that there's really no rule of thumb, right?

looks like you are arguing what "sparingly" means in that context because the rest of the sentence is totally valid. Stack and Heap allocation in C serve different purposes and there's really no rule of thumb to choose one and there's not even one case more frequent than the other. Allocate objects in the stack, it's faster. Unless you need a reference in a function in another context. Or it's too big. Or you're going going to share it between threads. Or whatever.

Having first-class functions and closures was the can of worms. How much you can get done passing callbacks is what got me wondering how much more stuff is there to learn in FP.

"insider trading" is one of funniest many exceptions to the rules of capitalism. Like someone said "The financial system works! you support companies you think will do good for profit! it's great, it will regulate itself! Only, you can only bet with bad information and we'll make great expense into regulating you are not using good info!.

That sounds like doing for code what we used to do for deployments before docker/kubernetes. Like going back from a declarative and reproducible aproach to a more procedural one. There's good reasons infrastructure as code took hold.

>many streets are designed as loops, making it impossible to use them to drive from one end of the city to the other. This solved a major problem—before the redesign, some streets were choked with nearly 30,000 cars a day, most of them simply passing through. Now, Lores told Citiscope, “If you enter by the south, you leave by the south.”

They got away with transient traffic and are now generating their traffic in adjacent communities. Smart.

Yeah. Like I remember the win 32 API (not saying it's a good API though) to typedef every struct and it's pointer. I'm not sure if the Linux API are the same though.

Others are pointing out the problem with staffing companies too, but this reminds me of my experience (different countries, so YMMV). This means that even though "The law allows for veil piercing" there's a huge maybe there, companies unloading their liability know this and have great lawyers. So IF a lawsuit gets to the real employer it's only after a LONG legal process, so not worth as much.

I can think of several countries with universal healthcare where hiring is still complicated to say the least. Not arguing it would still help, though!

Latin culture is about taking vegatables and turning them into bricks to be consumed with soft cheese.

>called Romeo & Juliet, one of the best food names ever created

The same format here is called Postre Vigilante "whatchman's dessert")

In Argentina in addition to membrillo there's dulce de batata!

const only means the variable itself can't be reassigned though, and really the main complain about mutation comes from Array methods. Like Array.pop will mutate the array and you have to do an Array.split for the last item instead if you want to keep your array.

I don't get the "arbitrary complexity" issue. It's only a problem if you're auto generating everything in your schema, but otherwise you limit the fields of problematic types by hand and that's it.

The same computatational challenges we've always had with mapping relational models to REST didn't go away, mainly: N+1 queries, recursive types and query parameters adding complexity.

It's most useful with anything sending multiple requests. Most often you have all the data to perform all requests beforehand, but you can't just fetch (or whatever xmlHttpRequest abstraction you like) to send all requests at once eagerly because of: performance in the browser (running something like 10 simultaneous ajax requests in a single tab often can really lag it) and rate limiting in the back end. So it's better to prepare all requests wrapped in a thunk and then you can execute them at will. You can really optimize as you like, like running some in parallel, secuentially or in batches. Of course this is for really custom cases, more often than not you are best served by something like Promise.map in bluebird which gives you a concurrency option. (http://bluebirdjs.com/docs/api/promise.map.html).

In Javascript you can make anything into a lazily evaluated expression by wrapping it into a function (sometimes called a "thunk").

// eager

new Promise(resolve => resolve(foo))

// lazy

const bar = () => new Promise(resolve => resolve(foo))

An executor would be something that takes n functions that return Promises and calls them.

>Your notion that forked = better is outdated.

You're beating a strawman here. Nowhere did I make the claim that it was better. I even said multithreading is more performant. The only claim I make is that immutable and shared nothing model of PHP servers makes horizontal scalling more straightforward.

>You're going to be using a thread pooled server anyway to handle requests

That doesn't take away the fact that n parallel requests will require n threads.

>And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc

I don't make any claims here either. Of course Java is faster here. My point was specifically about which model of concurrency and paralellism is better for server IO.

>Java is only suited for small to medium scale?

Never said that. What I said was that in the small to medium scale Java was obviously more performant because of the persistent instance & multithreaded model. But beyond that it really is no longer true. The immutable "shared nothing" process forking model of PHP scales horizontally very easily.

>Java web servers are multithreaded

this really is a disadvantage when scalling. The default linux thread stack is 1024k for 64-bit VMs, can't find what's the minium if you tweak it enough. You can see how bad that scalles to thousands of concurrent requests.

And then there's containerization and microservices, where each instance needs a full JVM.

>This is why companies like Google and Amazon run their stacks on Java

You can make anything scale with Google or Amazon budgets.

Again, just listing some pros and cons of both approaches, both of which I think are not even the best.

>What is PHP's multithreading model again

Since it's inception, the PHP implementation hasn't been threadsafe and since, the way of doing paralellism has been process forking. Later iterations where released with support for long-lived processes and threads but it's still not officially "stable" since again, historically the model of process forking made the ecosystem take for granted non-memory safety.

On the other hand, at least since the last time I was doing Java, paralellism is done via multithreading. Sure, there must be someone doing some else out there, but relevant frameworks like Spring work by making 1 thread by http request.

IMHO the right way of dealing with concurrency is the Node way. But comparing the PHP vs Java y think the PHP way is better. In small-medium scale the Java way is obviously more performant. The problem is when you scale to more instances. The PHP way of immutable processes really makes vertical scalling easier.

Funny, I just wasted a good while trying to modify the suggestions dropdown for an input in the react-select.

Not really, at least in my experience. The re-binding really isn't the same as the jquery way. React reuses the same event handlers, how it's implemented is another story and not really important anyway. The other issue is the fact that in the old way it's implicit that there's a mix of server and client side rendering. Say you have a grid of data that was rendered server-side. Then you update a row, which posts to an api endpoint and you get a reponse that represents your new row. At this point there's only a couple of ways this could be done:

1. you get a json object which you pass to a javascript function which re-renders the row's html and re-binds all interactive elements. 2. You get server rendered html from the server, which then leaves you to call a js function to re-bind all interactive elements.

some classic problems with this approach: 1. some rows data may depend on the data of other rows... now you have to sync client and server side state! (huge problem). 2. Remember that initial server-side view? guess what, all interactive elements had to be bound to the javascript handlers initially. Now you need code to initialize the view which is different to the one you use to do the partial updates. 3. Yes, I dind't even mention that we could send server rendered html full of inlined handlers as in "onClick=myClickHandler()". Because this leads to problem #2 right away.

I'm not saying React and friends are perfect, but it does solve all of this, at least IMHO.

Myself and most full stack devs in my circle using React used to do html/css/jquery before. Nobody misses the jquery days. As soon as you start fetching data from api and refreshing your UI you get into a mess. Let's not forget that most MVC frameworks from the era imply mixing server side rendering with some partial client-side rendering on UI updates. Re-rendering your html from templates client-side, re-binding your elements to its events... it's objectively worse both in runtime performance and development wise.

They are radically different. Corn is the textbook example of a commodity while land is the textbook example of a positional good.

You could sell any realistic amount of gourmet popcorn without affecting the supply of corn nor the price of other popcorn products, while selling housing affects the supply of land and the desirability of that housing stock.

I don't think it's relevant to compare popcorn to positional goods like housing.

Argentina has the highest salaries in many other jobs too.

Correlation is not causation and all that fuzz.

Also, that piece of propaganda conveniently forgets that Avianca just suffered the longest ever strike in Colombia, not really the most worker or union friendly place.

> Rising prices (not high prices) are great for people holding houses as investments

This is right. Part of the problem is that we don't refer to this by what it is: Inflation in housing prices.

The thing about housing is that you can't choose not to consume it. You can't anticipate your consumption to beat inflation either.

The only way to win with housing inflation is by exploting some subsidy like cheap leverage and the like.

Come on, I think it was clear that by "jobs locals don't want anyway" OP was talking about low wage-low status jobs filled by immigrants instead, that would otherwise offer higher and higher salaries until the supply curve met the demand one if interest group didn't inject immigrants into the supply -at least that's kind of the trump supporter angle-.

And in your deal I can see someone getting the short end of the stick:

The employer gets lower costs and higher profits. The Indian gets a higher salary and access to infrastructure he didn't have to pay for. The local gets a lower salary, and the rest of taxpayers get one more body consuming the public services he had to pay, more people competing for housing and ~40$K less in demand for whatever he has to offer.

>For the economy as a whole, abstracting away imports and exports, we can only eat what we sow.

Exactly. And "we" after all is another abstraction. And "I" can eat what "you" sowed.

If corporations have record-high profits, while workers get stagnating salaries while housing prices raise, someone is going to realize what "we" entices after all.