Nearly 100%. They don't call it that or use that term, and almost never _design_ thinking about the domain. But the absence of a formal 'domain model' still results in domain modeling - it's just done at the level of IC who may or may not have any awareness of the broader implications of the model they are creating.
> When I compare Java and Python in this respect -- and I do as a working programmer in both on a frequent basis -- Java is still slow.
I feel this as well, but I also think it's desirable. Java is slower to add features because the bar is quite a bit higher (especially with regard to backwards-compatibility).
I'd much rather have long previews and occasional removal of previews than have a language that becomes bloated and kneecapped by past rushed decisions.
There's Kotlin, Scala, Groovy, etc, if you want to run on the JVM with languages that offer more features (and footguns). I find the balance OK, personally.
I'd much rather them pull the `STR.` templates than push it forward knowing its not ergonomic in practice.
Going to assume you're talking frontend? Otherwise you'd be claiming most Spring, Django, Rails, Angular, <enter common backend framework> codebases are a nightmare to work in. While there are many good application architectures that don't fit into the MVC pattern (or introduce additional layers, e.g. - auth), separating DB ops (M) from business logic (C) and endpoint handlers (V) has always been rather maintainable/testable in my experience.
There are plenty of examples of real damage caused by ISPs being able to give preferential treatment to what _they_ think is important. A quick search comes up with plenty of examples:
1. ISPs limiting 3rd party VOIP solutions to avoid competition with their own VOIP solutions
2. Comcast blocking bitorrent communication was pretty obvious case of ISP preferentially limiting traffic
3. Verizon blocking text messages it didn't like the political message of
4. Verizon blocking 3rd party tethering apps, limiting users from using the bandwidth they pay for because they want to prevent competition
5. ATT prevented Facetime over their network unless users paid a higher subscription, even though users were already paying for data
6. Verizon limiting bandwidth for arbitrary reasons during natural disasters (first responders communication hampered due to limits justified through 'we don't need to follow net neutrality anymore')
Those are a few, there are MANY more examples in the US alone. Ya, some or many have been rolled back due to public outcry, but they shouldn't have happened to begin with. Allowing ISPs to determine which traffic is allowed based on their own self interest is just a terrible idea. Just because you haven't been harmed by it yet doesn't mean much, especially not in a country where the majority have only one or maybe two broadband ISPs to choose from. It WILL be abused, and we know this because it already has.
Do you have any examples post 2020, when net neutrality was revoked?
The internet has changed dramatically in the 10+ years since most of your examples and removal of net neutrality regulation has not seemed to cause any of those issues to resurface.
Twitch left Korea because of their crazy fees that would be prohibited under net neutrality. ISPs double dip and charge websites/companies like twitch, Youtube, etc to deliver data and also charge their users money at the same time.
https://restofworld.org/2024/south-korea-twitch-exit-problem...
>The problem stems from a “sender pays” rule instituted by South Korea’s Ministry of Science and ICT in 2016, to address the growing interconnection demands of video streaming and other bandwidth-intensive services. The rule requires companies to compensate the receiving networks for the traffic they send. It’s meant to tax heavy senders like Netflix and YouTube. Livestreaming sites like Twitch face particularly steep fees, as low latency is critical for live content.
>The “sender pays” model has been widely criticized by net neutrality advocates: In a recent statement calling for the repeal of the rule in the wake of Twitch’s exit, Open Net Korea warned that it “devastates the domestic content ecosystem” and “fragments the internet.”
One doesn't need an example from just a few months ago to see why this is a bad idea. Acting like the internet is so different today than 5/10 years ago so you can try to dismiss good examples is silly and acting in bad faith.
> One doesn't need an example from just a few months ago to see why this is a bad idea. Acting like the internet is so different today than 5/10 years ago so you can try to dismiss good examples is silly and acting in bad faith.
Also, it doesn't matter how old an example is: if we can all agree that companies doing this is bed, then we shouldn't allow it. "It was awful 10 years ago, and it would still be awful now, but it hasn't happened recently, so it must all be fine." is very short sighted.
Either net neutrality is good, and we should have it. Or net neutrality is bad, and you dont need "yeah but that was 10 years ago" as your counter. If you can make an argument for "ATT charging you to use facetime is a good thing", then make that argument. Not "but that was so long ago".
"Yeah I agree, those things were awful, lets make sure they happen again"
Interesting - I run Intellij Ultimate on Macbooks (both Intel and m2) and never have a crash. Infrequently run into bugs when upgrading the ide or 3rd party plugins; that requires some sort of cache invalidation or project reimport (couple times a year), but it's pretty smooth sailing for something I use across many different projects and languages. Java, kotlin, TS, python, groovy, shell scripting, json/xml/yaml/html/tsx are all generally touched 40+ hours on a weekly basis - it just works.
I do agree intellij is memory hungry with multiple projects open and a variety of languages involved, but RAM is cheap enough (and VMs/Docker/K8s hungry enough) that I just don't buy a machine with less than 32GB anyway, so I give intellij up to 6 GB and never give it another thought.
I don't do much android development, but do find Android Studio to feel clunky and slow at times, guessing because of the heavy integration with Android dependencies and emulation, but not really something I know enough about to comment with any sense of authority.
I think I view the situation in a similar fashion as you. There's absolutely nothing preventing a well architected modular monolith from establishing domain/module-specific persistence that is accessible only through APIs and connectable only through the owning domain/module. To accomplish that requires a decent application designer/architect, and yes, it needs to be considered ahead of time, but it's 100% doable and scalable across teams if needed.
There are definitely reasons why a microservice architecture could make sense for an organization, but "we don't have good application engineers/architects" should not be one of them. Going to a distributed microservice model because your teams aren't good enough to manage a modular monolith sounds like a recipe for disaster.
As in "this 748 square foot property was deemed 'affordable' when priced at $610k" - the implication being that it's a low bar to call something affordable, not that it's a low bar to _actually be_ affordable.
edit: sorry, this was already said by multiple other people - apparently had an outdated thread in the browser, those comments weren't there when I hit reply!
I work for a company (Inductive Automation), and we build a platform for industrial automation called Ignition. A few years back we created a special free license tier (and some light weight branding) for personal and educational use. It's called "Maker Edition", and there is a growing group of users using it for home automation. Mostly people already in the operational/industrial automation space, but it seems like it's growing more broadly.
We package Ignition as a docker image, an installer, or just a simple zip archive you can decompress and launch, so it's easy to self-host or deploy to a cheap cloud tier. The biggest downsides are that there will be a bit of a learning curve to using it (as with any new tool), the documentation being focused on commercial use cases, and similarly, we don't offer first party drivers for common home protocols (zigbee, zwave, etc). But we have pretty good docs, a free online learning platform, and pretty active forums. 3rd parties have written various drivers for home use.
I'd love for more in the home automation/maker space to know about and use it. We don't monetize maker edition in any way, and so don't really promote it, but I'd love to see the home userbase grow (and hopefully by extension, the hacker/maker community who might be able to help contribute to drivers and other resources).
It's an open platform built on the JRE, with a public sdk and example modules (plugins) and related tools available on github.com/inductiveautomation. The software is in use to automate virtually every industry, so it's fairly well tested (at least to the extent that a toolkit can be).
Disclosure : work for inductive automation, but otherwise don't have a financial interest in people using Ignition Maker Edition or anything of that (aside from any side effects that come from broader adoption in general). My selfish interest is in a larger home use community so there are more cool projects to check out, resources to share, open source modules published, etc.
