This phenomenon consistently happened to my college bus system, but on an even worse scale. The main bus line did a loop around campus, which took ~20 min to complete and buses scheduled every 5 minutes. In reality, you got a caravan of 4 busses arriving every 20 minutes, with the first one totally full and the last practically empty.
Tesla owner here. If you have the Tesla app installed on your phone, you can "share" addresses from map apps to it and it will auto-sync them to your car. So the workflow is open calendar on your phone, click on location for appointment, open with Tesla app. It's not quite as seamless as android auto, but much better than having to type everything in manually.
This is mostly true, but sometimes the cost of evaluating the condition itself is non-trivial. For example, if a and b are complex objects, even something as trivial as `if (a.equals(b)) ...` might take a relatively long time if the compiler/runtime can't prove a and b won't be modified between calls. In the worst case, a and b only differ in the last field checked by the equality method, and contain giant collections of some sort that must be iterated recursively to check equality.
> But 700x28 is really the maximum tire size you can possibly fit with rim brakes
This is patently false. Mountain bikes have been running tires over twice as wide on rim brakes for decades. I had one growing up in the 90s. Perhaps you mean caliper brakes? Even if so, I currently run 700x28c on my 10yo racing bike, I don't think I'd have any trouble going up a size or two.
I take it you've never actually cared for small children. One of the most obvious problems they solve is the ability to go outside earshot of the nursery - doesn't matter if the kid cries if you can't hear them! Besides that, kids often cry temporarily and then go back to sleep like 30 seconds later. It's very convenient to be able to detect if that's likely to be the case without having to walk across the house and open their door.
> This is one category of problem that should be solved through legislation, but I doubt that should such laws be passed, that they would be actually enforced against bad actors.
IANAL, but I would think this would be covered by existing false advertising laws, and maybe breach of contract. They advertised a product as coming with features x, y, and z; people paid for those features; and then the company unilaterally disabled those features. So now features x, y, and z no longer work on the product as advertised. I'd be surprised if we don't see class action lawsuits for this.
As a parent of two small kids, I just did an old cell phone running tinycam + generic ip webcam (amcrest makes a bunch of good ones). The dedicated cell phone is mostly for nannies/babysitters, I just have tinycam installed on my own. The only downside is it only works on your local network, but if you really care about that you can setup a home VPN. That last one is beyond the capability of the average consumer though.
If anyone wants this capability, the chrome extension uBlacklist ( https://chrome.google.com/webstore/detail/ublacklist/pncfbmi... ) provides it. I've found it very useful for removing github scraper sites from search results. Whenever you see a garbage result in a google search, you just click "Block this site" and it's gone forever.
Sorry, I didn't read your link carefully enough. I stand corrected, that does indeed seem to be the only reasonable interpretation. That said, this clause only exists in this particular OSL license, so it only applies to software distributed under it. Some quick googling indicates that OSL is 20 years old, and OSL v3 (the latest version), is 17. Despite that, it doesn't appear to have any significant usage. PyPi, for example, lists 10 software packages distributed under it [1], out of 387,658 total. So it certainly doesn't seem like a practical solution to the problem.
I suspect the reason that nobody uses it is due to its toxicity - it taints anything that transitively uses it in any practical way. This leads to all sorts of nonsensical violations. For example, say you write a document in a word processor that uses a leftpad lib distributed under this license. Then you email that document to someone else. Congratulations, you're now in violation of the license - you distributed a "derivative work" of the leftpad lib to someone "other than you" over a "network".
The terms of this license are so restrictive and cumbersome as to make it basically useless. Anything you publish under it can't effectively be used by the vast majority of the people who would want to use it, at which point you might as well not publish your work at all. I certainly wouldn't view this as a panacea for solving the SaaS-wrapping-OS-code problem.
My interpretation of that clause is it applies to distributing code over a network. The most common example of this is serving javascript to a web browser. I'm pretty sure putting an API in front of a server that happens to run open source software doesn't count as "distribution", which is what we're talking about here with SAAS providers and Akka. If it does, then every site that is backed by servers running linux and not distributing their GPL license to clients is also in violation.
I didn't say it wasn't a problem - if I could wave a magic wand and get rid of the concept of null in Java I would. That isn't what we're discussing though - you said, "The biggest thing missing in Java is an answer for the billion-dollar mistake [- NPEs]". I've provided what I consider to be at least a partial answer. If you care about avoiding NPEs in Java, it's a pretty good solution.
Realistically, null is so fundamental to the Java language that removing it would arguably result in a different language entirely. Certainly all existing java codebases would have to be refactored. The same goes for exceptions. That's obviously not an option when one of your primary selling points is backwards compatibility, so I'm not really sure what kind of solution you're looking for here.
The answer to your SO link notwithstanding, I would argue the @lombok.NonNull is at least one of the best options, as it actually generates a null check that is executed at runtime. This makes it more powerful than most of the other solutions.
> it doesn't matter how much the HotSpot JVM is tailored to OOP code
This is obviously false. The JVM, or any other compiler for that matter, is what translates the OOP code into CPU instructions. If it does that optimally, it won't matter what design pattern the top-level compiled language used. If it does it poorly, then it will.
> CPUs and RAM are not tailored to OOP in any way.
> Procedural code will always be more efficient with CPU and RAM...
First of all, arrays vs Lists and data type sizing are orthogonal to procedural vs OO code. You can write OO code that uses arrays and procedural code that uses lists, and datatype sizing is more related to your choice of language and compiler toolchain than your design patterns.
I think what you're trying to say here is that the performance ceiling for a low level language using simple language primitives (if-else and vanilla function calls instead of classes and polymorphism) that compiles to a binary is higher than that for a high level language that compiles to an intermediate language (or an interpreted language). This is generally true for small code paths - if you need to do a bunch of matrix operations, or data crunching for a small well defined problem, you can generally do it faster in C/C++ than in Java if you put in enough effort. The ceiling part matters though - in general, you have to put in a lot of skill and development effort to realize these differences, and this often grows super-linearly with the size of your codebase for low level languages. If you have a large application that has a lot of code, your overall performance will usually be higher with a high level language because the average performance for any particular part will be much better. Sure, given infinite time and resources you could theoretically do better in C, but nobody has that.
This is reflected in the approach most professionals take in practice when it comes to perf optimization - write most of your code in a high level language like Java or Python because on average it will be faster and less buggy for any reasonable amount of developer effort. For pieces of code that absolutely have to run as fast as possible, write them in C and call out to them from the high level language.
I guess the point I'm trying to make here is lots of people choose java precisely because performance is a concern. It does better than most other high level languages out there, and your average performance for a large codebase will be much better than something like C/C++ given the same amount of effort. As others have noted, it does multithreading better than most too, which is another major performance consideration. I don't care if my Java code is half the speed of the C equivalent if I can easily run 40 cores at once - or 40000. I think languages like Rust and Swift may let us have the best of both worlds in the future, but that remains to be seen. For now, the only time lower level procedural languages win is when you need a relatively small codebase to run absolutely as fast as possible.
I'm not sure you fully appreciate how tailored the JVM, and hotspot in particular, are to executing OOP oriented code. One great example I can think of is polymorphic methods. In C++ for example, you have to explicitly declare a class method as "virtual" in order for it to be polymorphic - i.e. the version called at runtime is tied to the runtime object instance, not the compile time type. This is because in order to do this in C++, there needs to be an extra lookup in the vtable to find the function address for every virtual function call at runtime. If C++ made all its methods virtual, it would take a significant performance hit from the extra vtable lookup for every function invocation.
In Java, all methods are virtual by default. Java also does the equivalent of a vtable lookup at runtime for function calls, but it has something C++ doesn't have - the hotspot optimizer. For any call site that is executed enough to affect runtime performance, the hotspot optimizer will optimize away the vtable lookup if there are only 1 or 2 method versions called at that site at runtime. This is true for the vast majority of cases. For most of the other cases, where you have 3 or more possible method implementations that could be invoked at a given call site, you would probably have to have something like a vtable lookup at that call site whether you use OOP or not (switch statement, if-else, explicit table of function pointers, etc), so you're not losing performance there either. The end result is, the JVM gets polymorphic methods basically for free in terms of performance.
This is just one example, there are many other clever things the JVM does to make OOP code performant. I don't have a citation, but I do recall seeing a talk (maybe by James Gosling?) where he mentioned that one of the primary design goals of Java was to make "doing the right thing" from an OOP perspective also the best option for performance.
It doesn't fully solve the problem, but @lombok.NonNull helps a lot. It makes it clear which properties shouldn't be null, and catches NPEs closer to the source. Incidentally, lombok in general does wonders for boilerplate reduction.
On any sort of list structure, a "find" operation generally means searching the list in order for an element that satisfies a predicate, usually equality to a given value. The article could be more clear about this, but in this context finding the last element in a list means calling find() on a list where only the last element of the list matches the predicate. This is almost the worst case scenario (the worst case being no elements in the list match). If you read the code in the article, you can see it's using https://www.cplusplus.com/reference/algorithm/find/ to find an element in the list of value 1, after inserting that as the last element in the list.
The point is, it doesn't matter if you know the length of the list, you still have to examine all the elements.
> Kindly show me where I was making a cost comparison between nuclear and solar in my original comment
Ok. "There simply isn't a comparison between nuclear and solar. Nuclear is a far better solution on all fronts... The comparison is brutally tilted in favor of nuclear." Two of the most important factors in choosing a grid-scale energy solution are cost and time to deployment, so they're included in your statement. Perhaps you intended to convey a different assertion, but based on any reasonable interpretation of what you actually wrote, @ncmncm didn't divert the conversation, he focused it on a subset of your claim.
> The simplest calculations clearly show this...
> That led to creating a series of mid-sophistication models to try to arrive at parameters, from technical to financial.
Ah, so we've gone from the "simplest calculations" to "a series of mid-sophistication models" :)
> [I] predicted we would need between 900 GW and 1400 GW of new, additional power generation. I[n] other words, we would have to double what we have now.
I haven't done any research to verify this, but based on your reasonable assumption of transport fleet electrification, these numbers seem reasonable. So we agree we'll need more electricity generation in the future. I don't see how that's evidence that nuclear is a better source for it than solar.
Why not? None of the evidence you've provided supports this assertion.
> [Solar] can be a part of it...
Your original assertion was that, "The comparison is brutally tilted in favor of nuclear." An obvious corollary is that we should invest all our resources into nuclear deployment instead of solar. By saying solar can be a part of it, you're implicitly changing your original position.
> So, my claim was simple: In order to build a solar system that delivers power equivalent to that of a nuclear power plant you need a system with at least 7 times the peak generation rating.
The sources I cited above say a factor of 4 - 6, but it obviously varies a lot depending on climate and latitude. So sure, let's say 7 conservatively. So what? Even taking that into account, solar is still a fraction the cost of nuclear. It has myriad other advantages such as being faster to deploy, safer, has unlimited fuel, doesn't have any significant waste products, has much more predictable costs, etc. So why should we bother investing in new nuclear deployments?
I realize you're saying you're not making an economic argument, but you haven't made any other kind of argument either. The biggest thing nuclear wins on is steady output - as everyone knows, we can't rely on solar generation 24/7. So perhaps that's what you're trying to get at? As sister threads have discussed, however, a) we have a lot of solar to install before we have to worry about excess peak capacity, and b) there's been great progress in utility-scale energy storage systems which mitigate this problem.
Agreed, it's actually fairly impressive. Beware the false equivalence fallacy however - there's little overlap in the expertise needed to design and install a home solar array, and that needed to analyze the economics of complex industrial technologies. Based on my links above, I think op is a far better electrician than economist.
Also, I doubt op ever built a nuclear reactor in his backyard :D
I'm certainly not an expert on nuclear vs solar energy, although I do have some background knowledge. As with many things, I make up for my lack of expertise by seeking the analyses and opinions of real experts. No offense, but I trust them over a rando on HN who built a solar array in his backyard :) . A simple google search of "nuclear vs solar cost" strongly suggests that you are very wrong - nuclear is far more expensive than solar, and the gap is growing as solar gets cheaper. Of the first four results[1][2][3][4], only one argued that nuclear was even remotely competitive[3], and it's 6 years out of date and the most convincing data it cites is from 2005.
I found [4] to be the most straightforward and pithy explanation. Basically, nuclear wins on capacity factor, but solar makes up for it by a) still being cheaper even when you have to build 4-6 times more capacity, and b) it takes 10 years to build a nuclear plant vs 1 for solar, so you get to start using your electricity and paying off capex (and reducing CO2 emissions) much sooner.
Now it's possible all these sources are so deeply flawed that they came to the completely wrong conclusion, but the onus is on you to present evidence of your assertion and provide a convincing argument. Saying (and I'm obviously paraphrasing here), "the calculations are simple and you all are idiot sheep" doesn't cut it.