There is a nuance though, because a language simply being interpreted does not mean it is being used as a scripting language. Take for example Java and C#, those languages are interpreted by default which allow you to ship platform-agnostic binaries and a bunch of other neat features. C# can be used as a scripting language, whenever it is interpreted, but it does not have too. It is an important nuance and this is why you can’t just replace the term “scripting language” entirely. You can also compile C# directly into machine code, skipping the interpreter entirely. Technically, there is nothing stopping you from writing an application that use C# as a scripting language even without the interpreter, since you can compile c# to machine code and simply dynamically load the library at runtime (kind of like Unity does). I guess you could call those “embedded languages”, and it would mean almost exactly the same thing, but then, aren’t we back to the same problem of some developers taking offence from that? I mean, it does imply that the language does not stand on its own without machine code just as well, which is true. This is one weird hill to have a bruised ego over for those developers you’ve met. Words have meaning and this one just happen to be a right fit given the description. I have a feeling from this whole exchange that you didn’t know what scripting languages were, considering how you replied to my first post. I worked in development for over a decade and I have never seen it be used with negative implications. I really just think you personally projected your own feeling onto a term you didn’t understand. No offence intended, it happens.

There are definitely people out there shitting on all sort of languages, and JS is a huge target, but those have been referred to as scripting language for as long as they existed. It stern from the fact those languages are embedded into existing applications, as opposed to being built into binaries. Nowadays you have hybrids like C# which can used as either a scripting language or to build native app (or in-betwee), so it is really just a matter of the context you’re using the language in. There is inherently no hidden meaning or elitism in the term. It is a very old term and I think you simply got the wrong impression from your internet experiences. It is how those languages are defined basically everywhere. Even some of those languages official definition from their own website self-define as scripting languages. There is no ambiguity here at all.

I wanted to get back to you, because you are so very right, and I spent the last 10 years or so trying to evangelize the fact that implementing algorithm and logic isn’t the hard part, it is a trivial concern really. Everything that go wrong with development usually involve the flow of data, and figuring out how to get this data from over here to over there without making a big mess. To do that, you absolutely need to write small module with few dependencies. You gotta think about the life-cycle of your objects, and generally follow all the principles of s.o.l.i.d if you’re doing OOP. Personally, I really love using dependency injection when the project allows for it.

It is as you said really, you can have thousands of hours of programming experience but if you never tried to solve those issues you’re really limiting yourself. Some devs think designing software around your data instead of your algorithms is overthinking it, or “overengineering” as I have been told. Well, I would not hire those people for sure.

I have seen clean project made up of small modules, with clear boundaries between data, functions and the lifecycle configurations. It is night and day compared to most code bases. It is really striking just how much of the hidden, and not-so-hidden complexity and goo and hacks and big-ass functions in most code base really just exist because the application life cycle management is often non-existent. In a “proper” code base, you shouldn’t have to wonder how to fetch a dependency, or if an object is initialized and valid, and where to instantiate your module, or even what constructor to invoke to build a new object. This take care of so much useless code it is insane.

To close on this, I like scripting languages a lot as well, and you can do great things with some of them even if lot of developers don’t. JS has Typescript, ReactiveX, dependency injection framework, and etc. It is a great language with a lot of possibility, and you’re not forced into OOP which I think is great (OOP and functional programming are orthogonal solutions imo). But the reality is that the language is really easy to misuse and you can definitely learn bad traits from it. Same as you, I would be wary of a developer with no experience with strongly-typed languages, or at the very least TS. I am very happy to hear this take randomly on the internet, because in my experience, this is not how most developers operate, and imo it is demonstrably wrong to not design applications around your data.

I freaking love you and I’ll try to write a worthy reply when I am home.

True that, this was pretty much the intended meaning of my reply but you worded it better.

Python and Js are by definition scripting languages in the classical sense. I am not using the term in a derogatory way and I myself learnt programming this way as a 90s kid. No offense but I think you took my comment way too personal.

I worked under a self-proclamed Python/JavaScript programmer, and part of the job involved doing rather advanced stuff in various other typed languages like c# and c++. It was hell. The code review were hell. For every little tiny weenie little things we had to go through “why coding c++ like it is python” is a very bad idea.

What is crazy about developers who exclusively work with scripting languages is that they have no conception of why general good practices exist, and they often will make up their own rules based on their own quirks. In my previous example, the developer in question was the author of a codebase that was in literal development hell, but he was adamant on not changing his ways. I’d definitely be wary of hiring someone who exclusively worked with scripting language, and sometime it is less work to train someone who is a blank slate rather than try to deprogram years of bad habits.

In some countries we’re taught to treat implicit multiplications as a block, as if it was surrounded by parenthesis. Not sure what exactly this convention is called, but afaic this shit was never ambiguous here. It is a convention thing, there is no right or wrong as the convention needs to be given first. It is like arguing the spelling of color vs colour.

Who on earth would rely on a game engine in bankruptcy?

They aren't nearing bankruptcy first of all, and I as I mentioned even in this doom-and-gloom scenario they would likely just get acquired and operations would continue as normal. Is that what you think? That Unity is about to go bankrupt? I am not sure what we're arguing here.

Engines need a constant conveyor belt of new games to sustain their revenues and I don’t see this happening.

What are you basing this observation on? Unity never made money from the volume of games released using their engine. Also, the part where everyone is suddenly dropping Unity is mostly just a narrative here on social media, and the bulk of the reason why it might not be happening is that there is no true alternative.

And yes there is pain and a learning curve to moving to other engines though I think most programmers would be able to cope with change and if they’re that incurious and inflexible that they can’t then maybe it’s time to find new programmers

It is not about coping and being incurious. Changing engine means trashing a part of your team, trashing your content pipeline, trashing your internal tools. It costs a lot of money, money which most studios don't have. It would make sense if there was a true alternative to Unity for those mid-sized studios, which there isn't.

As for Godot, I am sure it is not a 100% feature for feature replacement for Unity. But it sure as hell is capable of powering 95% of indie games out there no trouble whatsoever and I daresay some more challenging titles

Again, not sure what you're basing those numbers on. Godot can't even do consoles natively so there is definitely some troubles and headache in using Godot in 2023. I would agree that Godot is perfectly fine for solo devs and very, very small teams, but it is not a serious alternative for even mid-sized productions. It is still pretty much a toy compared to the bigger engines, and it lacks commercial support to really attract those studios.

I get it. The popular sentiment here is that Unity is doomed to fail, and the internet as a whole kind of wish it did. I am not gonna gather sympathy and votes by saying otherwise, but I just don't see it. Godot is not ready, switching to Unreal does not make much sense since it is the same proprietary "garbage". It is easy to make big statements here on Lemmy and claim how easy it would be for game studios to get rid of Unity, and how this would improve their business, but to be honest I don't think you guys have a clue. If you are actually a developer or own a game studio then I am sorry for assuming.

Unity is not going anywhere, even in a bankruptcy it would get acquired by the likes of Microsoft or Meta. The "good guys startup" Unity is long gone, and it's been replaced by the same corporate structure you would expect anywhere.

Tying yourself to Unreal would be just as naive, and Godot is nowhere ready to fill the niche Unity is filling. I would place the opposite bet as yours, the vast majority of actual game devs are not rich enough nor care enough about corporate drama to ever switch engine for possibly worst. Also, experienced C# Unity devs and experienced C++ Unreal devs are not that interchangeable. Unity made this move to survive and they know there is no true alternative.

This is my pov, I worked in the industry for over a decade and I am an Unity ex-employee.

I’ve seen this play out a couple time. I agree about a lot of what you said and this is indeed true that you can have very senior and very knowledgeable devs basically “hack” or “bulldoze” their way into a backlog, I would personally argue that this is not a decent or desirable behavior.

There is no such thing as “small finition”. Making sure that a change or a feature works all the way through is not finition, it is core to the task, and you can’t expect someone else to digest and do the latter half of the work without being in your head.

I guess I am too lazy to type out all the examples with the downfall, but basically if you allow this, you will be shielding a senior from his own butched work, and lets be honest, most people who do this skip the “boring” work for their own selfish reasons. If they want to split the task and have you fix the tests, have them spell it out and justify it.

Management might not understand what is going on, all they might see is a superstar flying through the backlog, while everyone else struggle because they’re constantly fixing this guy’s shit. This rarely lead to good engineering, or team dynamic, or team management, and of course you end up with this one guy claiming credit for so much shit, while other team members stagnate. Unfortunately appearance is a thing in dev work, as much as I wish it wasn’t.

I read the Tweet, it does not “show” that the account had purchased games. This has been Ubisoft’s policy for years and there is no record of deleted account, except for a random tweet.

This is misleading and ragebait. They only delete old-ass accounts without purchased games, and this is a compliance thing with European laws.

It certainly adds up, and it makes maintaining the databases more complex and costly as a whole.

Imo this is just lazy, they could at the very least “archive” old accounts and move the bare minimum data out of the main DB, as to make it possible to reactivate the account later on. Why can virtually every platform keep old account arround, but not Ubisoft?