Or use tig. It's a great CLI tool to view git status, stage/unstage, and view history. And I never really hear anyone talk about it.
Melamine is a weird exception. It absorbs microwaves for some reason, which is why it isn't recommended for microwave use.
Which they could have done a much better job with.
It was basically just hosted SVN if I remember right, and they never added git support when it became the de facto version control system.
In my experience, Java has a lot fewer breaking changes with upgrades compared to other languages. Compared to Python or even PHP and Java looks slow, steady, and predictable.
I'm somewhat confused by your statements, so perhaps I don't understand.
Function/objects that allow changing their behavior by passing different objects into them, based on some interface, is called dependency injection. Some subset of behavior is determined by this passed behavior. E.g. To keep a logger class from having to understand how to write logs, you could create a WriteTo interface and various implementations like WriteToDatabase, WriteToFile, WriteToStdout, WriteToNull.
When you create this example logger, you'll need to make a choice of what object to pass when you write the code. e.g. new Logger(new WriteToDatabase(config)) But maybe you don't want to make that decision yet -- you want to let a config file decide which writer(s) to create. The pattern to pick between dependencies at runtime is called a factory. In this case, you might make a WriterFactory to pick the right writer, or perhaps a LoggerFactory to hide the creation of both Writer and Factory objects.
So, a factory is only really a facade to hide the runtime switching of how an object is created.
Also, the term dependency injection often gets confused with what you see in various Java / C# / and various frameworks in other languages -- those usually use what's called a "DI Container" or "IoC Container". These manage and facilitate how dependency injection happens within the project, often with various annotations (e.g.@Autowired). These containers are powerful, but sometimes complicated.
However, you can absolutely still do DI without DI containers, and I think advocating for not using DI generally (and related patterns like factories) is rather misguided.
What got you interested in programming (or tech in general)? And what was your first language/programming experience?
There is a version mismatch. lemmy.world is having trouble upgrading, which I believe also causes federation between instances to fail between these versions.
They have a thread about it here
The opposite actually happened to me. PHP was my first non-intern position. That company eventually started working with Java, so I made that transition when they did.
I've found pair programming to be fantastic, but only when used rarely in certain situations.
If you've got a good rapport with a teammate and a legacy project has landed in your lap neither of you understand, I've found pair programming to be the fastest way to figure out how it works. As you work together, you'll both understand different parts of it better and be able to quickly figure out what's going on. I guess this is probably less pair-programming and more like collaborative dissection of code though.
I've also used it to help onboard people on a project fairly quickly. This is more tricky and much less comfortable to do, so I do my best to stay in tune with what they need from me, and tends to be me coding for a bit and them following along and asking questions. Eventually, they want to start writing some code, and a day or so of switching back and forth is as far as I've usually taken that. I think it's useful to break down barriers when working with (especially new) people, to make mistakes in front of them, and build good rapport.
I've not used it much beyond those situations, but I'd definitely use it in these ways again.
Yeah. I grew up playing the NES and it was very much the spark that caused me to get so interested in technology (and eventually programming).
A few years ago, I discovered the NES homebrew scene and learned so much. After a few weeks, I basically got some basics working, but the environment is not forgiving and I never quite clicked with 6502 assembly.
PICO-8, on the other hand, offers similar asset restriction with a very friendly environment. It's not perfect (and Lua is hardly a favorite language of mine), but it's fun.
I might revisit NES homebrew eventually, but PICO-8 scratches that itch for me right now.
I've watched so much good code written professionally die because of the whims of leadership in the past.
I'm reluctant to call much "bloat", because even if I don't use something doesn't mean it isn't useful, to other people or future me.
I used to code in vim (plus all sorts of plugins), starting in college where IDEs weren't particularly encouraged or necessary for small projects. I continued to use this setup professionally because it worked well enough and every IDE I tried for the main language I was using wasn't great.
However, I eventually found IDEs that worked for the language(s) I needed and I don't have any interest in going back to a minimalistic (vim or otherwise) setup again. It's not that the IDE does things that can't be done with vim generally, but having a tool that understands the code, environment, and provides useful tooling is invaluable to me. I find being able to do things with some automation (like renaming or refactoring) is so much safer, faster, and enjoyable than doing it by hand.
Features I look for/use most often:
Features I don't use or care so much about? Is there much left?
I do code in non-IDE environments from time to time, but this is almost always because of a lack of tooling than anything else. (Like PICO-8 development)