dpc_pw

Unlike the other responder, I am actually not big fan of multiple selections and prefer search and replace. But once in a while multiple selections come handy even for me, so I don't mind them being there.

If IDE works for you and you enjoy it, stick with it. I enjoy modal editing (Vim/kak) because it feels good. I don't have to move my hands from the home row and I'm a damn impatient person, so that fast editing just makes me feel a little better about "waiting for IO".

I've switched from Vim to Kakoune 3 years ago, and lack of support for this modal editing style elsewhere is really frustrating. It is better than Vim's, but in practice that's not a significant difference, and the pain of switching back and forth is something I'm agonizing over all the time.

BTW. The exact kakoune modal editing mode is not even all that flawless. The way x and X work on empty lines is infuriating, and I am actually using a personal fork of kakoune to fix it. https://github.com/dpc/kakoune-dpc . I went so far as prototyping a spinoff of Kakoune: https://github.com/dpc/breeze to look for improvement, but building a full-featured text editor is a lot of work, and I it's not like it's going to fix the problem of switching.

Storing fields in a map leads me to believe this is not Data Oriented Design (DOD). And I completely reject this idea (fields in maps). The "flexibility" there is hardly useful, and could be achieved with defined shapes (types) in modern statically typed languages without all the dowsides.

"Separate code from data" is a big core belief I share with this article, but the rest doesn't seem good idea / novel / important.

People willing to help out with `npm-crev` implementation needed. :)

If people are crazy-buying TSLA stock, TSLA can issue more stock. If people are piling crazily into corporate treasuries and the yields are going down, corporations will issue more debt (and e.g. buy back more of their own stocks). When people were pilling up into a housing bubble in 2005, the builders were creating mc mansions like crazy as well.

All the financial assets are prone to systemic over leveraging, and fiat money central bank induced bubble is affecting absolutely every asset: housing, debt (private & public), equity, derivatives. Different things explode at the time, and central banks need to run to the rescue by blowing the bubble even bigger.

If it weren't for fiat money bubble, derivatives would be mostly rational markets as well.

Derivatives are transaction between to parties like any other. One side pays money the other takes money for making certain bet.

The problems I'm aware of with derivaties is that it makes easier for companies to hide their speculative bets off the balance sheet, and it exaggerates overleveraged long-term bets. But it's hardly a root of all evil.

This article is nonsense. It absolutely fails to make a point.

It's not like up-scaling stuff with neural networks is going to introduce a random mobile phone into the medium being upscaled or introduce any other glaring misrepresentations. The upscaling is purely for improving quality.

Accuracy of the colors is rather secondary. And if anything, historians should just help out if they can.

Personally I've spent a lot of time watching upscaled&colorized videos on YT, and I'm just mesmerized. It's sooo much more vivid and gripping to look at the past like we can look at the present.

Other than Python's `with` and alikes, wrapping in a closure, `defer`/`scope` (Go/D), what else is there? What am I missing? None of these work if the lifetime of a resource is not a simple "this scope".

But it's a good advice. For some reason people tend to forget that copying stuff is super cheap, and most lifetime issues can be entirely avoided with a `.clone()`.

https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no...

Ownership model seems hard for people to internalize, but once learned feels very natural, leads to programs that are better structured and frees programmer from "manually managing resources".

All there is just bunch of subjective experiences in specific circumstances.

I definitely agree that one can paint themselves into a static-typing corner where refactoring becomes painful (but as I said, usually because of OOP). Also in big projects care needs to be taken to keep compilation times manageable.

> Languages should facilitate thinking of enforced correctness as a gradual concept, like gradual typing in Python, so the programmer has freedom to make these choices.

Depends on the domain. In web-based non-critical applications, maybe. If there's a bug, users gets and error etc. reports it, you push a fix to prod and things are usually OK. In things I mostly worked with (embedded, automotive, on-premise appliances, systems, p2p, finance), the cost of debugging and fixing small bugs is far too high.

I am supporter of gradual typing though, if someone wants to go with dynamic typing route.

I agree. It's not unlike what you can do with reflections and other dynamic features of dynamicaly-typed languages. So it's not a problem of static typing itself. It's a problem of taking a feature of the language and strangling the code with it.

I had to do some refactors of JS code where everything was a shapeless objects with random fields, as the language doesn't even nudge the developer into considerations like keeping consistent "shapes" of data. Had similar experiences with some Python code, where I had to fight both data types fuzziness, reflective-features inventions (hello __getattr__!) and OOP over-abstracted nonsense at the same time.

One way or another, in larger teams/projects dynamic typing just doesn't scale. Type system works like a most basic documentation / developer aid / consistency encouragment, even if it is pushed into complexity nightmare.

I don't think I've ever even seen a reasonably well working large project in a dynamically-typed language...

IMO, static typing gets blamed for problems that are usually caused by OOP: complexity caused by needless abstractions (mostly inheritance taxonomies).

IMO, That's not type system but OOP. Where I have problems with types is usually due to class hierarchies, and developers trying to invent "beautiful" taxonomies and abstractions for the sake of abstractions.

I guess generics sometimes come as a cludge too, particularly if they are combined with the above OOP issues.

In a typical bussiness/app code if you don't use inheritance or keep it to minimum, and use generics where they belong, static typing is rather mindless. "This needs something that implements interface ServiceA, and a string" and then a bit of familiarity with handling collections and "Options".

From my experience, it's only sudoku puzzles if you (code author) make it so. Not very unlike the opposite version when people go very wild with abilities of lack/dynamic typing.

It's hard to build anything larger. In a microservice architecture one of the best things one can do is to define machine-readable schema (which is just a way to "type" RPC calls and messages) for all APIs/messages/events, and then auto-generate generate client code from it.

Most of the people who oppose typing must have been working on tiny projects, in small teams where they were co-authors of most of the code.

You literary compare 3 languages that you happened to use and think that all there is to know about this argument.

The only reason why interpreted languages are usually much slower is semantics of the language itself. And maybe JITing itself, but that tends to get amortized rather quickly.

Rust is just a more modern, better and more approachable programming language than C and C++, and people care about it more and prefer to get their little system programming lessons in it.

> I disagree - I always test a real database, never mock it.

I always put an interface between the IO part and rest of the code, so I can either mock it or not. Ideally I would have a separate tests making sure that the real-IO implementation of the interface works, and not use in my normal test that are exercising logic. But it is indeed a lot of additional work, so I'm cutting the corners and let the test run against a real db implementation, only wrapping it in things like injecting faults etc.

However as per which test types to use: the right answer is (as with everything) "it depends".

When doing testing the overarching problem is that the testing was well thought. Different types of testing will behave differently at different scales and different problems.

Instead developers oftentimes thing in terms of WHAT, not WHY. One can't just do the same thing for completely different projects and expect the same results.

Most of the time best testing is opportunistic - one that does what's easy and fast to achieve.

In some apps functional test will test mostly separate and shallow code paths, which will not lead to a lot of coupling.

With some languages a good type-system is already a 90% of unit test suite.

A big part of testing is also designing your production code to be testable. (TDD is good here because it forces you to think about it upfront). With a right architecture even e2e test can be great.

Web-browser is not very profitable bussines, and by bloating web with more and more complexity, we made sure maintaining alternative implementations is getting harder and more costly.

The Web degenerated into it's natural conclusion - a centralized platform controlled by a handful of corporations extracting value from its users.

Seriously, better start exploring alternatives already if you care about your privacy and freedom, because this route is gone.

For some reason SWE oftentimes hope to achieve some general-AI level tooling and methodologies that would magically let them ignore everything other than than aspect they desire to change.

Something as simple as opening a file of code requires IDE, because everything is hidden behind `./src/main/java/com/whatever` nonsense. The language was designed for IDE.

In Rust there is hardly any need for IDE (or a debugger), as long as your text editor has LSP support. Hell, even without LSP support it feels quite OK to write Rust code.

I use Intellij for Java, and Kakoune for Rust, and I really dislike working with Java. The fancy refactoring features don't make up for how verbose, clunky and inexpressive Java is.

The Rust way is to have great modular and reusable tooling for everything. Even stuff like complex refactoring can be achieved without an IDE with something like https://github.com/google/rerast

Superficially it looks to me like bunch of theoreticians overcomplicated everything, and it will never be practical. Probably great project to advance your academic carrier though. But maybe I'm wrong.