SomeCallMeTim

Very true, but #EndSoftwarePatents can and should be a thing.

I actually take a position that some software maybe should be patentable, but that it's such a tiny percentage of what actually GETS patented that it's likely better to simply prohibit/invalidate all software patents than to allow only certain software patents. The backlog of hundreds of thousands of obviously-bad software patents wouldn't really be able to be individually reviewed by the experts that should be able to invalidate them, and software has copyright and trade secret protections available. That should be good enough for 99.9% of circumstances.

The patent office has clearly proven that they can't be trusted to discern "novelty" in software development, and I don't see that changing any time soon, so time to prohibit the system from applying to software at all. At present it's 100% prohibiting the small inventors from innovating (or allowing a few patent trolls to extorts those who succeed) and 0% allowing small innovators from profiting from their products.

Actually, in my experience using the default random implementation in games:

* It's not fast enough. * It has patterns that can be seen if you are using it to, for instance, generate 2d noise.

So for games you'd typically use, say, the Mersenne Twister [1], which is faster (amortized) and is distributed evenly across 623 dimensions. [2]

It's not cryptographic, but it's far better for games. If you're not going to have a crypto default random, better to at least have a really good and really fast one.

[1] https://en.wikipedia.org/wiki/Mersenne_twister

[2] http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.p...

I was on a project-from-hell once where the project lead cared far more about getting types perfect than allowing the code to be, you know, useful.

If we couldn't do something 100% type-safe then we weren't supposed to do it at all. I kid you not.

I got off of that project as soon as I could manage without burning a bridge. Funny thing was that before that? I thought I was quite the stickler for getting types as correct as possible. Turns out I was off by an order of magnitude of what a real "stickler" for correct types could be...

Totally agree with you.

Some of the rebuttals below seem to be saying "But I use them differently!" Bully for them, but 99% of the time when it's not set, you don't really care why it's not set because it's not defined yet or because it's been set to `null`.

And any time they assume it can only be null OR undefined but not either, there's a chance for a bug. Even if I "know" it can only ever be null and not undefined, it's safer to just say != null rather than !== null.

Treating them differently in a code base is a legit semantic, but testing with != null works no matter the intended semantics.

PostgreSQL directly supports table sharding. https://pgdash.io/blog/postgres-11-sharding.html

Schema evolution is supported by pretty much every ORM you'd care to use; it's not the job of the SQL database to handle the migration. I'm using Prisma and you literally change the software spec for the schema and say "migrate", and it creates the migration SQL and applies it to the Postgres DB programmatically. That gets you deterministic schema evolution and not the "my schema isn't actually reliable" that NoSQL/no-schema databases rely on.

And then you have CockroachDB/YugabyteDB that give you extreme horizontal scalability, with full PostgreSQL compatibility...

And bang, the last reason to use MongoDB vanishes.

I felt that Abramov's article showed...nothing useful at all.

Yes, he found an abstraction that turned out to be not useful. But that doesn't mean there wasn't an abstraction that could have been useful. Or even that the judgment call that his exact abstraction wasn't useful was correct.

DRY is important. Maybe he didn't find the right abstraction, but for the most part it's possible to refactor repetitious code with readable abstractions.

I find DRY to be useful in some cases even when there's only a second copy of the code. I hate seeing any duplicate code past a certain level of complexity. Other times I'll copy a few lines of code all over the place and not worry about it.

The core conclusion I've come to is to take ALL such "rules" with a grain of salt. Programming is a skilled craft, and there are no rules that you can apply universally.

Still no Node or npm compatibility? Not even on their roadmap? Still think Deno is DOA, then.

TypeScript is great, sure. I love TypeScript. But I wouldn't touch Deno for just about any serious development if I couldn't be certain that I could search npm for a library and use it without a potential hassle.

Maybe?

It's hardly martyring to be kicked off of Twitter IMO, but even if his fans see it that way -- Trumps fans seem to predominantly posses a very short attention span.

It's the only way that many of Trumps reversals make sense. They can be cheering him for saying A and then cheering him five minutes later for saying ~A. I suspect that if Trump loses his platform for some number of months, the shine may wear off.

And Parler is being kicked from AWS, so their entire service is going down too--and they may get the full treatment of being kicked from other servers and payment services if they don't agree to police their content. And without easy access to his marks, it will be harder for Don the Con to stay relevant.

Not predicting that it will happen. I'm not that optimistic, TBH. But positing a mechanism that it could happen.

I think the extremes are straw men. The choice isn't between "duct tape" or "oven-engineering." It's between poor and good design.

A well designed solution doesn't feel like duct tape, nor should it be "too clever" with a crazy multiple-inheritance architecture that no one but the author can understand.

In fact, it sounds like the extremes described in this article are both crap developers, with different flavors of crap on the menu.

I insist on solid engineering. Nothing that feels like duct tape, but nothing that approaches over-engineering either. Easy to understand and easy to extend to the point of "OF COURSE this makes sense!"

It's not so much "in the middle" as "robust design vs one or another flavor of garbage." A strong designer is needed to get to that point, and maybe duct tape is better for shipping product than over-engineering, so if you HAVE to choose, the duct tape end of the spectrum is better. But even better to have a solid software architect who can come up with a good solution that people can use and extend and understand.

> A list of banned words and opinions will never make the world progressive. Deplatforming people over truly just opinions or mannerisms is a temporary win.

When people know their opinions are generally considered reprehensible, they hide them. I can agree with that.

But if those opinions are successfully hidden or pushed underground, and the next generation is predominantly exposed to positive values, the world does become more progressive. Individuals change only a small amount, you're right, but society does change for the better over time.

It's when echo-chambers of intolerance exist that attitudes of intolerance and selfishness can be amplified and push the world in the wrong direction.

I hope you're right.

The obituaries for Trump's popularity have been predicted so many times that it's hard to be confident that "This Time It's Different."

> GOAL encourages an imperative programming style: programs tend to consist of a sequence of events to be executed rather than the functional programming style of functions to be evaluated recursively.

That alone is a pretty hard condemnation of LISP/functional for games.

It's not really LISP/Scheme at that point, but a LISP-ish syntax for an imperative language.

Some tasks are more innately imperative. Games (and game scripting) are in that category. Trying to force game programming to work in FP is like trying to build a computer in Minecraft: It's cool to see that it can be done, but it doesn't say anything about whether it should be done.

Proving Turing Completeness doesn't mean you would want to actually write code in a Turing Machine.

Be careful about asking "Did you Duck yourself?" though.

I have a hard time trusting _any_ of the password services that host my passwords.

Single point of failure. Even if they claim they're "encrypted so that even THEY can see them", it's so easy to mess up encryption, it makes it a single point of failure.

I still share passwords between my devices though, but instead I use KeePass along with the Android app. For less critical passwords I let Chrome keep them; I _mostly_ trust Google, and non-critical passwords are exactly my level of trust of Google.

And I also trust Google to share my (encrypted) KeePass file with my devices. But now it's two points of failure: Someone would have to break into a private Google Drive, get my KeePass file, and break the KeePass encryption.

And I trust _both_ KeePass _and_ Google more than I trust Lasspass to get security right.

I'm hearing this complaint a lot about React Native in particular: That Facebook's "Move Fast And Break Things" philosophy is alive and well in the management of the project.

Most recently the stories were about specific controls that worked on Android but on on iOS, and then the new version arrives, breaks the Android behavior but fixes the iOS behavior...or vice versa, sometimes for the same control, in a later release.

I've heard better things about NativeScript; it's actually a more mature project than React Native, and has a lot of features that React Native lacks. And it's apparently a lot more stable.

But fewer people use NativeScript, so it's possible that I'm just not hearing as many of the horror stories. Also curious about Weex.

But I'm not making apps right now, so I haven't tried any of the above. People keep wanting to pay me lots of money to work on easy backend projects. Who am I to say no? :)

ROT-8000 is only touching the first 65536 Unicode characters (UCS-2). Unicode has >1M code points. [0]

Most emojis seem to be above the first 16 bits. [1] But there are a number of emojis in the first 16 bits, like the "frowning face" emoji at U+2639 -- it rotates just fine -- plus others in the first 16 bits.

(TIL you can't paste emojis into HN comment threads. Probably all for the best.)

[0] https://en.wikipedia.org/wiki/Unicode

[1] https://unicode.org/emoji/charts/emoji-list.html

Unlike your coworker, I _always_ have a plan. Often a dozen of them. With various pros and cons for each.

But also unlike your coworker, I probably _figured out how to do it right_ in the time given. It's pretty rare that I don't have time to do it right; it does happen (especially with extreme instances of scope creep and requirements drift), but it's rare.

Which I guess is your point? The time excuse is just an excuse, and a good developer writes good code.

I think it's more like the fact that my joystick cables always get tangled, no matter what I do

The entropy of the creation and evolution of software gets tangled. We can do our utmost best, but unless we spend an equal (or sometimes greater) amount of time untangling (refactoring), and unless customers' needs suddenly become simple and static and uniform so we don't need to be adding features, we'll still have jobs.

I am in Dallas at least once per year.

A couple months ago I was there, and around my wife's parents' house, almost every yard had a Beto sign.

So I can verify that this is true, at least for some parts of Dallas.

On-demand Server Side Rendering should be killed for 98% of applications.

SSR->static hosting + client framework is the future.

Framing is useful in politics, but I think the underlying limitation here isn't preconceived notions that you're trying to overcome but the inherent complexity of the system you're suggesting.

Say for instance you make the unit of design the unit of update. Then any breaking changes means the unit needs to support both old and new methods of access. This is often appropriate for something like a public API used by thousands of people. But if used at every resolution, it would add too much complexity and need for legacy handling of access patterns.

So if the unit of update is instead a self-contained ecosystem of components, then the components can all be simultaneously updated, reducing their internal complexity. The external interface should still probably be versioned.

And...well, you've just again wrapped up something in that self-contained ecosystem that could very well be called a "program." In fact, it could also be called an object oriented program: Each component is an object that has an API and hidden data.

I'm a fan of static typing, so I'd answer a firm yes to that question. How they communicate -- message passing seems the right paradigm in most situations. So the interesting (to me) solution would be to standardize static types over a message passing architecture. Something like Google's Protobuf? Or JSON with JSON Schemas? Who knows. Depends on the nature of the problem you're trying to solve.

And that gets to one final point: Most programmers aren't capable of thinking in big systemic terms like this. Probably 90% of developers are going to be restricted to operating within a component. I think this is why React and other web client component architectures are so popular today: They are great enablers of average developers (and, to be fair, can be high leverage for great developers as well -- at least up until the point where they get in the way).

This felt to me like a roundabout way of saying "we should think more about design!"

I _agree_ that we should think more about systems design. And I _agree_ that the individual "units" that we're designing would benefit from standard ways of communicating with each other.

The entire thing about "let's not call it a program!" feels like a distraction from the core point, though. I guess I don't really believe that calling the "unit of software development that I'm currently working on" a program harms it or limits it in any way.

Even in the article, the author talks about isolated spaces:

>While the Smalltalk model holds a large number of objects in a single ‘space’ - we could imagine a system where each object has internal space which holds a cluster of inner objects, and so on.

...and so, poof, we now have a unit of software that could easily be called a "program." A program that contains multiple layers of inner program, but there's nothing about the word "program" that limits how it can be applied.

So I think 95% of this article is philosophical semantic gymnastics. There's a seed of an interesting idea -- software would benefit from the ability to connect its pieces more flexibly -- but without an actionable hint as to how to _get_ there, this is just a pointless intellectual exercise.

Changing the word to something else doesn't actually make the problem easier to solve.

Assembly is very readable with enough practice.

Source: I've ported multiple assembly language games from one assembly language to another.

You can always "opt out" by not using the web site, unfortunately.

So I don't know that they would lose any challenge on those grounds.

They passed a tax on plastic bags in Boulder (CO).

You go to the supermarket without your reusable bags, suddenly you're _paying_ for the bags.

You better believe that disposable plastic bag usage went _way_ down. People don't like to pay for what they're used to getting for free. It makes them unreasonably angry, in fact.

Angry enough to remember to bring their reusable bags, or to buy some on the spot.

Just saying that both SPAs and NoSQL have had _more_ than enough time to mature. It's not like they both were invented a decade ago; they were a decade _mature_ a decade ago.

It's slow (execution speed [1] -- it's slower than Node.js by a lot!), and every developer that I've spoken to has given very, very long estimates (from my POV) for accomplishing even trivial API work, so it seems to be prone to low development velocity. It's possible that every single Java developer I've worked with is nigh incompetent, but they had jobs at places like Oracle, Amazon, and high-end consulting companies, so I'm not sure where the strong Spring developers are hiding.

I don't know the internal architecture, but given the poor benchmark results, I'd hazard a guess that Spring also functions as a thread-per-connection server, which means resource use would be very high for real-time applications (compared to Node.js or an event-based Java framework). And most applications today require at least a real-time component, so if you need 10x-50x as many application servers because you need an OS thread per concurrent connection, that's a huge additional cost.

[1] https://www.techempower.com/benchmarks/ -- Java and C++ tend to be the fastest in the benchmarks, but Spring is so slow that it hits between 2-16% of the top platform speeds, depending on benchmark.

Sounds like your architect was a bad fit.

Uncomfortable with Docker? Today? Or microservices? Or mixing Kotlin with Java?

I haven't used gRPC myself, but it looks like a strong standard. I have used Protocol Buffers in the past, though, and I certainly wouldn't be afraid of it just because I hadn't used it.

I've seen this kind of ultra-conservative outlook with Java developers fresh from enterprise jobs. Worked with one developer briefly who insisted that every new API would take at least two weeks of work. Even if the API was completely trivial CRUD. When I mentioned that I was using a framework that could stand up a new CRUD API in minutes, complete with authentication, validation, and user-based access protection, the developer called me a liar.

Which was funny because I'd just done _exactly that_ for another client, standing up the entire stack _and_ creating ~40 CRUD REST APIs (with parallel Socket.io APIs for real time updates) in about 8 hours. Adding or changing a model for one of the databases from that point forward just required a few lines of model specification code; additional custom code per-API was entirely optional. Of course I wasn't using Java Spring, so that may have been an unfair advantage, but there's a reason I don't use Java Spring...

Why make it either-or?

I prefer NoSQL when there are scaling needs, because it _can_ scale horizontally. Sometimes it's just easier to use, too, and there are times when the feature set maps _much_ better onto the problem at hand.

Not all of your data access needs to scale horizontally, though, and if you have relational data you should use a relational database unless your scaling needs are extreme.