Hello

sorry for the delay -- hello!

how can I help you today?

When importing an SVG into Android, can't I load it programmatically? (It's an XML after import)

if you mean that you used the Vector Asset Wizard, you should have gotten a drawable resource as a result

Yes, I mean that

And I can load that drawable?

yes, like any other drawable resource

so, @drawable/whatever or R.drawable.whatever

Thansk :D

I think I'm a bit confused as we use glide to load some images/drawables and that doesn't work anymore after we started to use imported .svg, as glide doesn't know what to do with the .xml. But I guess I can either teach it to do so or not load the images via glide at that place, right?

presumably

I forget whether Glide can load resources or not

I mean, I know it can for placeholders and errors

I haven't ever used Glide + resources for loading the "real" image content

It can load resources, but it cannot load .svgs or .xml as a standard

iirc

OK, you lost me there

I think I have to go back and look at my code to see what is done exactly :D

But I'd have a question about Kotlin

You state that Kotlin is one of the most complex programming languages. I wondered why it designed that way, as it feels like a pretty big disadvantage for me.

~80% of the functionality developers need can come from ~20% of the language syntax (all percentages very approximate)

But you have to be really disciplined to stick to the 20 %, it feels.

no, you just ignore stuff that looks weird :-)

I fear doing a project in Kotlin and handing it over to someone else who doesn't understand squat.

so, if you see some code snippet somewhere that refers to a tailrec keyword, that's probably not something ordinary developers need

Something which isn't as big of a thing with Java for example.

eh, developers are able to not understand squat in any programming language :-)

I agree that it is easier to create confusing Kotlin code than it is to create confusing Java code

Sure, you can write it that way. It just seems that it's easier in Kotlin, as it can be part of the syntax, not how the developer uses it.

I have read through your Kotlin book, hence the questions ;-)

getting back to your root question, Kotlin is written that way to maximize how much of Kotlin can be in a standard library (itself written in Kotlin) compared to being part of an actual core language engine

the smaller the engine, the easier it is to rewrite that engine for other environments (Kotlin/JVM, Kotlin/JS, Kotlin/Native)

a side benefit is that it gives that expressive power to library developers, so libraries can have streamlined APIs that resemble core language features

That is why Kotlin is complex?

however, that side benefit comes at a cost: a lot of the syntax for enabling that expressive power can be fairly arcane

and so you run the risk of ordinary developers using that stuff in ordinary apps and causing problems for the "doesn't understand squat" crowd

this is not unique to Kotlin -- Ruby has some of the same traits

basically, rather than the language itself putting up guardrails to protect the "doesn't understand squat" group, the onus is on intermediate and advanced developers to clearly separate their code

so that a library might be easy to use (for the "doesn't understand squat" group) but require more Kotlin experience to maintain

only time will tell how well this approach works in practice

Only time will tell...

it was a bit of a problem for Ruby, but there it gets exacerbated by the language being interpreted and duck-typed rather than compiled and statically-typed

programming languages are experiments in how to get humans to teach computers what to do

we don't know how the experiments will turn out until we go through them

which is why we have lots and lots and lots and lots of programming languages

of course, eventually, computers will just program themselves, leading inevitably to SkyNet, muscle-bound Austrians stating "I'll be back", etc.

But it's gonna be a couple of years before we're out of a job like that.

Let's see if it's before or after I picked up Android ;-)

it's more that languages succeed or fail in "the marketplace of ideas", and their successors sometimes learn from the mistakes

so, 15 years ago, Ruby was "where it's at", and nowadays it is far less favored

this does not make Ruby evil, nor does it mean that all Ruby code written is an unmaintainable mess, or anything

it means that Ruby had its issues, which affected the team that use it

all languages do the same thing, to varying degrees based on popularity and problem density

languages are also a bit of a fashion statement, so Ruby went from "all the cool kids are using Ruby" to "Ruby? ugh" in a decade

we may be using Kotlin in 20 years, or we may not

What's your take on why Python seems to be kinda stable in that regard?

frankly, I have no idea

while some languages I understand their unexpected longevity (Objective-C, I'm looking at you), I haven't quite understood how Python has hung around

'cause Python is pretty old

not C old, but up there

That's what makes it interesting for me. Could mean that Python has done something very right

possibly, but syntactically-relevant whitespace makes me cringe

or, more accurately, syntactically-relevant indent levels

a lot of the time, what drives the "fashion statement" aspect of the language is some specific use of that language

for Ruby, it was Rails

for Kotlin, in many respects, it is Android

for Objective-C, it was Steve Jobs

The hope is that Kotlin can do more

yes, and it is already used for more, just as Ruby was used for more than Rails

my book generation scripts are all in Ruby, for example

(with some slow migrations in a Kotlin-y direction)

in some cases, it doesn't really have "legs" beyond the primary use case -- I don't know of Objective-C being used for a ton outside of Mac/iOS development

and so once the primary use case moves on, the popularity can change in heartbeat

in the case of Objective-C, the introduction of Swift tanked Objective-C's popularity, because Mac/iOS moved en masse to Swift

Especially nowadays with so many languages. For a lot of the purposes you could use Kotlin besides Android there is a language that does it better.

in many ways, I think that there are actually fewer languages now than, say, 25 years ago

I think that there are more languages being used "for realz" now, though

How are there actually fewer languages?

oh, there were tons and tons of languages in the 80's and 90's that either had their heyday (BASIC, Pascal) or were more experimental (Forth)

some have lived on (BASIC -> Visual Basic, LISP), while others died off (SNOBOL)

back then, if you were a computer science major, writing a programming language was almost a rite of passage

most of those never made it past homework assignments, but some did

nowadays, creating a programming language is in some ways easier, due to better tools

but creating a programming language that people will try is harder, because we have a lot more history with a lot more languages that we did 25-30 years ago

(er, "than we did")

and a lot of the use cases for a programming language might be handled in other ways today (e.g., XML/JSON data structures processed by a regular programming language, or a DSL written in a regular programming language)

I see.

OK, that's a wrap for today's chat

next one is Thursday in the 7:30pm US Eastern time slot

thank you

have a pleasant day, and stay healthy!

Have a good time