airless_bar

Just read my other reply.

Wrong.

You are obviously wrong.

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.

Scala! Great language, huge ecosystem, good tooling, many platforms supported.

This only seems to be an issue for languages where packages reside in a global namespace, like Python, Rust etc.

I think most languages these days are a bit smarter and avoid this beginner mistake (for various reasons).

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".

Hey, they are Google! Java 6 is probably the most "modern" thing they can think of!

Costly: yes.

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.

To save him time and frustration due to his project going nowhere?

I think it's a very valid question. Given that the constraints by the Python BDFL rule out any reasonable solution, why not move on?

For example, you have both an option types and `null`, and libraries being inconsistent in which they pick.

Which ones?

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.)

Comes off as a bit "me too" from my perspective.

In the whole list of things there is literally only a single thing which isn't already shipping/existing in Scala.

I agree with lmm. The only thing where Kotlin wins is in marketing and hype.

No?

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.)

Missing values are not errors.

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.

Sorry, was meant to be a light-hearted response.

The whole point of this was to show that Scala's types preserve the structure of the computation.

It might not be very interesting in the Option[Option[String]] case but imagine Try[Either[String, Int]] or List[Future[Double]].

It's a very important distinction.

Collapsing cases is one of the primary thing why exceptions sometimes get a bad rap, and Kotlin (and Ceylon) do the same with ? (and |, &) at the value level.

Yeah, it's just that-if you look at every language ever designed-if the language ships with a built-in construct developers will use and abuse it on every occasion, and every other approach lingers in obscurity.

Which is expected since these two constructs are not aimed at handling errors: they manage missing values.

Which is a very small part of handling errors in general. As Kotlin offers special syntax for only this case, developers tend to shoehorn many errors into the "missing-value" design to get the "nice" syntax even if a different approach would have been more appropriate.

Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...).

That's not true in practice:

Just have a look at funktionale: Despite providing almost the same as Scala's error handling types (partially due to the blatant copyright violations) almost nobody uses it. This is a direct result from having a "first-class" construct in the language: It turns library-based designs into second-class citizens.

That's the thing Scala got right, and many of the copy-cat languages got wrong.

Not really.

The main strength of the first approach is that Option is only one type out of many error-handling structures.

Not every error is handled appropriately by Option/?.

If you have a language like Kotlin where they hard-coded one way of handling errors, it feels very unidiomatic to pick a better fitting error handling type, while in languages where errors are handled by library code, it's a very natural approach.

formal name

non-shitty

a trend in newer languages

yes, only discovered a few decades ago

:-D

They preserve the structure of the computation.

  Option[Option[String]] != String??

I can recommend Scala.

The libraries are top-notch and unlikely to be found in other languages due to the superior typesystem.

It has broad tooling support, and Scala's JavaScript backend is stable, mature and actually works (unlike some other JVM languages' JS backends which currently exist mostly in marketing speeches).

Standard Googler behavior. :-)

Ah alright. yes, I think it makes more sense to define the GUI with code. Typed resources help with it.

sbt-android-gradle has full support for Gradle projects, but to be honest: Gradle is utter shit. Just use the SBT plugin. it works so much better. The latest version even manages SDK and NDK for you.

Which GUI tools do you have in mind?