I feel like I’ve responded this before, but I feel like people often attribute their increased knowledge of how to develop systems without bugs to the new fancy language they switched to.
Fact is they could build better software in the old language as well, assuming they started from scratch.
I strongly disagree. We use a strongly typed Lua-like language at my company and it has everything you need to build decent applications, but we hit so many bugs. It took me 12 hours over 5 days to make a simple modification to the business logic (half of that was figuring out and fixing bugs). It took me 4 hours to write something far more complex in Rust with virtually zero bugs; I attribute this almost entirely to sum types (Rust enums), a better type system, an unforgiving compiler, async/await, a better module system, lifetime checking, and an ecosystem of easy-to-grok libraries.
These things just make bugs disappear.
When it comes to IDE experience, the parts that I use often are mostly the same between Rust and our language.
Edit: I'd say it's both, in a multiplicative manner. You need experience and a good set of tools (the language itself being the most important tool) to write good code fast.
I attribute this almost entirely to sum types (Rust enums), a better type system, an unforgiving compiler, async/await, a better module system, lifetime checking...
This seems like an example of a language effectively abstracting common complexities and pain points, which were probably discovered in earlier languages...
I think it's fair to say that rust is the first mainstream languages bringing these notions out of the woods. Who on earth knows about ML or cyclone ? 0.0001% of the programming crowd maybe.
World operates in spirals. We branch off trying things and then go back to old forgotten ideas, etc etc
Kotlin has sealed classes which are basically the same as Rust's enums. It also has async / await in the form of coroutines and a decent module system. It also doesn't need manual memory management, which while unsuitable for many applications does remove another potential class of bugs.
> We use a strongly typed Lua-like language at my company [...]
Is this homegrown? In my experience this alone has a major impact in productivity because it is generally hard to create a good implementation and a new language and/or implementation only pays when the existing solution is too bad. (Source: I have made a Lua type checker at work. It worked, but fell into disuse as I moved on and the entire org abandoned Lua in spite of my work.)
Erm surely ability is important as well. Programming is no different in this regard to pro sports - some people have more talent (which probably in turn breaks down into innate attributes, determination and learning opportunity earlier in life).
Some people really don't get programming while others do.
When I studied at university many years ago, my course had a reputation for being tough. Before the course started properly, there was a three week intensive Java course with an exam at the end. They suggested that if you didn't pass the exam, then it probably wasn't the subject for you. A couple of people failed that exam and continued with the rest of the year long course anyway. Those people did struggle and I don't think any of them passed.
Are you arguing that all tools are equal? Or that some tools are better than others but the difference is negligible compared to experience? I don’t agree that experience is everything (if by everything you mean that all other factors have zero influence).
I'd argue that no matter how "good" you are, you are capped at what tools you're using.
Consider using a hammer against a pneumatic tool. A newbie will hose you with better tools, they're wielding that condensed knowledge at their hands, their sum overshadow yours with only a hammer.
In my opinion it's usually worse using a new framework or language as you don't know the ins and outs of it. Your first project is going to be a learning experience in that technology. I have seen plenty of Python code that was clearly written by Java developers wanting to try out something new.
Figuring out the Mikado method was one of the bigger shocks of my career. I thought I already knew all this stuff, and of course once I saw it I could explain it all. But knowing something is true and seeing it first hand can be a very different experience.
The simpler solution is often hard to see. We get attached to the wrong details or suffer sunk cost fallacies.
When you switch languages the cost of porting is higher, so it shouldn’t be a surprise that you end up with something much simpler. And if the target language attracted you because it makes some part of the problem simpler, that’s important but maybe not the dominant contributing factor to the experience.
I'd agree, but some tools just make it easier to design and build a complex system whatever the level of experience of the programmer(s), designers and so on.
This programming language and IDE https://en.wikipedia.org/wiki/Clarion_(programming_language) is behind some of the biggest databases in the world. Because of the openess of the IDE, in one instance it was possible to migrate one country's main cancer charity app from ISAM files to MS SQL, and rewrite it from procedural to OOP code in just two hours! Admittedly it took a week to build a program to do the coding changes, but that program became a tool in its own right to migrate other programs, but the original devs thought it would take a human 3months to do the work, which is already several months less than if the program was written in another language!
Various banks and other stock market listed companies. Even various military use it for their own top secret work.
The key to its success is the template language, which enables the programmers to work at a higher level of abstraction which for some reason just doesnt seem popular amongst many programmers. You can use the templates to write code in other languages, including Java, PHP, ASP.net, javescript and more.
Its safe to say, that everyone in the Western world will have some of their details stored in a Clarion built database, and its not just limited to building databases, its even been used to build highly scalable webservers.
Theres also C/C++, Assembler and Modula-2 built into the compiler, so you can get right down to low level coding if required, and there's a Clarion.net version which is mainly like C# but has some of the data handling benefits of F#.
I can attest to this but it's definitely misleading. Some languages have features and patterns that are straightforward and easy to learn in that language, that once you've learnt you can emulate/replicate in almost every other language but only because you already know how it works, why it works and where the limits of your abstraction are.
And these abstractions will be often be overlooked or misused by developers who have not used them in languages where they're native; making them a net negative instead of an obvious benefit.
People are going to jump on the imprecise wording here but this is generally correct. People need to be very wary of "let's just throw this out and start over". There are cases where it makes sense, but 95% of the time it amounts to "the old code is complicated and it's a lot more fun to start over than it is to figure out the old stuff some other guy wrote". The old code is complex because it actually works and has taken the punches of production deployment.
Most often, people start down this path bright-eyed and bushy-tailed, and end up realizing after about 4 months that actually all that complication was doing something pretty useful. People need to be careful before they dismiss real working-in-the-wild code.
Rebuilds are generally a bad idea, and I've never had a good experience doing that. Apart from what you've already stated, it's kind of an insult to the team before you, that you just deleted their code.
Replacing a system is also not really solving a problem that the business cares about. So this enevitably leads to feature creep, "If you're rebuilding it, can you add X, Y, Z...". This then leads raises the bar even higher...
The better alternative is to modularize the system somehow and replace seperate chunks... but that's easier said than done
It does play but no. Languages and paradigms do make a difference. I had to come up with a tiny DP answer for a java interview and it was a massive burden. Even though I could write the same (quality and perf) version in other languages in 2 minutes.
This can be validated or refuted by going back to that language and building something. If the same old roadblocks reappear, it was the darned language, after all.
Fact is they could build better software in the old language as well, assuming they started from scratch.