While attacking a single package would be possible, covering any interesting amount of "typo"-space would require registering huge amounts of namespaces.
If package manager developers are smart, the allocation of namespaces is also handled externally and associated with some cost (e. g. domain names).
Therefore these kinds of attacks become impractical.
I don't think anyone considers Python or Java modern.
Nevertheless, this isn't about where adoption comes from, it's about how the language design was influenced by the advancements in language design in the last 40 years.
I think dismissing anything invented after 1960/not invented at Google counts as "inflexible and unadaptable; unable to keep up with new languages or idioms".
Why not use another language? I think it's a perfectly valid question for that guy to ask.
My personal opinion on "Why not use another language" is a bit different though:
Adopting a different language might make sense – not necessarily for technical reasons but for cultural. The technical issues could have been addressed in time, and the language would be in a much better situation today.
The fact that the technical issues have not been addressed for such a long time shows a clear lack of leadership and focus. I think these cultural issues are a bigger problem than the technical issues. You can fix code, but you can't fix people.
I don't believe that the question was meant to be a joke or a trolling attempt.
The guy's competence isn't the issue. It's the requirements of what the fix can and cannot do.
_Everything_ is a mess due to the massive technical debt of never improving key parts of the runtime.
I mean what's the point of a runtime where adding threads makes things magnitudes slower than running in a single-thread?
"But that's just the state right now, they will fix this!"
No, they won't. Just as a perspective: People usually fight over a single percent of improvement or less when working on runtime concurrency. Nobody just goes in and fixes _magnitudes_ of performance issues without rethinking what has been done and picking a completely different approach.
This is not about making things "faster". This is literally going from doing necessary work to discovering a way of not having to do the work at all anymore.
That's just not going to happen. Neither locks nor reference counting have anywhere near this optimization potential given the current language semantics.
I think the whole (C)Python community missed the train more than a decade ago.
Things that necessarily had to happen just didn't happen.
Many communities and groups of developers "professionalize" over time. This doesn't seem to have happened in Python.
Just an example: C extensions. It has been clear for at least a decade that the existing C interface won't work for threading, "real" garbage collection, etc.
What would have been smart: Providing a better interface 10 years ago, effectively giving C ext devs 10 years of time to migrate their code. This way efforts to remove the GIL today would have to satisfy one fewer constraint that's currently crippling all of the efforts.
Same with a lot of other things ... getting rid of the GIL would have required changes to various parts of the stack over the years (GC, language -> Python 3?, APIs ...), turning the actual removal of the GIL just into a final act of a multi-step process.
What actually happened: Nothing. And now they just try to break the large lock into millions of smaller locks ... in 2016. WAT? This just tells me that key people in the Python community never really gave a damn about the issue and therefore this guy will waste his time.
I have never expected Python's demise, but it now seems that largely its culture and not its lacking technology brought it down for good. From my perspective, they should have never released Python 3 with a GIL. That's what broke Python's neck, finally.
Yes, Scala is great. Way ahead in terms of providing developers with useful tools compared to most other languages. (It's not the usual run-of-the-mill language which takes Java and adds some syntactic sugar, so some effort in learning and understanding the language is required.)
> I think the idea that API's (or implementations as you said) can be copyrighted is completely insane and I can't believe any software engineer would be okay with it. Which makes me think you're not a software engineer, and that's okay, but please read up on the issues, this is super important for our profession.
I think you are super confused here. This is not about APIs. Copyright is what allows software developers to enforce a license of their choice. Without copyright, the license is just a text file without meaning. I suggest you read up on the FSF's position on this if you want to have an example.
> Sure.
(Still waiting for you to comment on the points I have made.)
Call it whatever you want. ? only covers a small subset of interesting "conditions" while tremendously hurting "conditions" which could be handled in a better way.
> Uh copyright what? On an API?!?
Implementation. The copying of slightly buggy exceptions strings makes it even more obvious that files were copied verbatim with just enough syntax changes to turn Scala code into Kotlin code while replacing the original license and authors with different ones.
PS: Feel free to comment on actual the points I made.