Is this a portable aircon or built-in?

built into the house

kk. no experience of that, I have a portable one. sorry can't be of further help! 😞

One thing to look for is an external controller that would have a separate temperature sensor. Ideally also a humidity sensor. (Not entirely related, but you should also have a CO2 sensor and never let CO2 rise above 800 ppm).

The book Thinking In Systems (you can find the PDF online) has a whole section explaining why the target temp is rarely exactly even with the actual temp. Basically, you have two competing feedback loops that result in some oscillation and there's a bit of a lag. You could also improve the situation by improving the insulation.

@UPWHQK562 has proposed a plausible explanation, but my rule is to always look for the simplest answer: which is: If the thermostat setting does not relate to the result, it is a sign that you have a smart AC but the thermostat is in a different part of Spain and, in turn, your thermostat controls someone else's AC. The installer probably forgot that the ISP assigns only temporary IP addresses. There is nothing you can do about that. But luckily Spain has plenty of cool alternatives. You can always go to a nearby coast or ride the Renfe Ave and ask the conductor to open the window.

BTW. The aircon in my part Spain is an open door. Kind’a sucks too.

Oh... so smart and on-prem are two different things? They could market it like that. Maybe I could buy the smartness separately from AC... and even without ever investing into AC... seems like a good case for subscription-based pricing :rolling_on_the_floor_laughing:

That is not a very fair comparison. React advertises itself as a library, not a framework 🙂

And React.js itself doesn't handle state at all, right? Or maybe it's just started to in the latest release? So folks have always had the choice of which state-handling library to use...

Maybe they are comparing it to how Rails is in Ruby

Clojure: very few frameworks - hard to decide which libraries to use. JS: so many frameworks - hard to decide which one to use. But libraries >>> frameworks.

Yes, maybe it isn't fair, but Reagent is also a library, and it didn't change how state is managed since basically forever. React had setState, then some magic props, then tried atomic (or something like this), and hooks

(It's also interesting that React advises itself as a library, but create-react-app creates a node_modules with 357mb of dependencies )

create-react-app is a separate thing though, and it adds a lot of things on top of just React. React is still a library.

React has state, it used to have classes with instances that had state in its instances, now it’s render functions with hooks that basically are like values that react will remember between renders and return in order. What react traditionally didn’t solve is how to deal with state on a macro level, it has component state, it has callbacks, but it didn’t tell you how to propagate that across an app. That’s where libraries like redux came from, those allow you to publish/subscribe to parts of a larger state somewhere up the tree.

> React is a library. It lets you put components together, but it doesn’t prescribe how to do routing and data fetching. To build an entire app with React, we recommend a full-stack React framework like Next.js or Remix.

from React's website. when people don't use a framework with react they just end up making their own bespoke framework that does everything a differently from the next bespoke framework, which is what you're seeing

clojure has the same issue, imo

or, not an issue, more like you can observe that it's the same case with clojure. whether it's a problem or not is subjective

it appears that go ppl have the same philosophy, they tend to advocate the use of standard library and not to use frameworks

I mean I think it's generally a good choice to be reluctant to bring in dependencies and go's stdlib is unusually good, so I get it

using is bad, global using is worse, being able to have it in any source file is worse still. There are some use cases when it's more good than harm to use something like that. IMO such use cases are rare and global using will be ill-used much more frequently, resulting in lots of people spending lots of time chasing compilation (or maybe even run time) problems. But we probably won't hear about those before some conference in give or take a decade, where some speaker will tell everyone how "this neat little trick" cost his company hundreds of thousands of dollars.

Been doing c# professionally for couple of decades, I think it's a great feature.

We had no problem with Common Lisp packages, and sth like that would be wonderful for Clojure, especially when refactoring. An app pretty much had one package. If there was a clearly delineated, substantial self-contained library, it could get its own package. But those would noramlly be separate projects altogether.

Mind you, some CL pros go the other way on this. But we executed a 100kloc enterprise app with one package and it went fine.

I've been in the same .NET codebase for ~10 years now, and I've only had problems with using 1-2 times, and even then it only took me 2 minutes to fix. (Previously unambiguous reference became ambiguous, like you would expect). Agree it can be abused, but I think there are actually big problems the other way too. E.g., without global usings/requires you have to have a lint rule that people always import clojure.string with the same alias to not cause confusion, and hopefully everyone has an editor that does it automatically so it doesn't slow them down, etc.

That's my feeling too, which is relying on linting of some kind to enforce common aliases is moving the work from the compiler to the linter.

The punch line is that a famous CL saying was, "It is probably a package problem. It is always a package problem." When using tiny little packages,

It feels like a hack to enable ersatz language extension. (I’m not saying hacks are bad. They can be useful).

Testing it in a new project and I have just added one thing so far: global using Dict = System.Collections.Generic.Dictionary<string, object>; In ClojureScript, I would probably try: clojure.string :as str clojure.set :as set, goog.object :as gobj and maybe a couple of more.

Overt require's have clued me in to emergent wrong-way (untidy) references, so I think they are a good thing. But in principle, isn't this just another example of easy-vs-simple? Simple=evident references, even if tedious. Easy=declaration-free, the compiler can make sense out of darn near anything.

I think it is simpler only if you focus on one particular part of the process of writing software. If you look at the whole picture, it isn't obvious to me that it is simpler overall, considering the downsides like requiring a linter, having to constantly verify what namespace is aliases as s, etc.

Well, here's the crazy thing. I actually went from mono-package, if you will, to a dozen distinguishable packages and then all the way back, because "distinguishable" was like static typing: plausibly beneficial but not in fact. And to @U0HG4EHMH’s point, yes, during a three day effort I did come up with two improvements to encapsulation, but they were neglible code quality wins. Just was not worth it. By simply programming well -- easier with a Lisp! -- we had achieved 98% of the "win" of small packages. Meanwhile, neat specific packages in practice led to, as advertised, the hell of "It is always a package problem.", with especially hard-to-diagnose bugs. Which is why I took the hit of converting back...I kinda cheated and had all the distinct packages just reflect a common mono. Anyway... We went back to mono and... imagine putting down a ninety pound knapsack. But developers are emotional beasts -- mileage varies.

Tagged readers are global

this feels like something that's less of a problem in languages amenable to more complete static analysis: when you're wondering what something is, or where it's used, it's trivial for your IDE to figure it out for you. the tediousness of duplicating requires/imports across a codebase in clojure helps serve that same purpose, it makes it easier to see what is used within a file and overall where libraries are used across a codebase. contrast that with how ruby works, where requiring code always has global effects and makes the library content available everywhere: and it's often impossible to know where behavior comes from just by reading the code and it's a little maddening