Porting Java concept exercises for Kotlin?

Exercism
21

Yeah I want to exclude myself from writing the content (just reviewing and fixing / amending) so that I can “do” the track as we build it, giving you more or less fresh eyes each time!

That said, happy to help with exercises-from-scratch if we need them!

And obvi @kahgoh would love your involvement!

2 Likes
22

So obvious that I didn’t even think to suggest it!

Warning: I am almost completely useless at thinking up new exercises. If there’s nothing available to port from another track, I get stuck.

23

I’m quite good at it, so (ab)use me when you need me!

Porting is probably best for 80% and only kotlin-unique features need new exercises. Recently @SneakyMallard has made really nice additions to the JS syllabus and together we came up with refined set of tests, goals, and story, so I am certain that with some community effort we’ll be fine.

2 Likes
24

If you need another tester who is more or less a complete Kotlin beginner, feel free to ping me.

2 Likes
25

As we get more exercises merged, it will be a bit inconvenient that only the track maintainer (DJ in this case) can see the syllabus on the Exercism website.

@iHiD, is there any easy way to relax this a bit? I don’t know how any of these would work out, without a painful website rewrite (that you don’t want to do!):

  • recent authors on this track?
  • active maintainers on any track?
  • individuals who ping you and ask nicely?
  • individuals who ping you with a cash bribe?

If a bunch of people are contributing to just the syllabus, we don’t want to intrude on the current sole-maintainer status.

1 Like
26

The section on rounding turned out longer and more complicated than I expected!

27

No worries, I’m happy to look into porting the concept exercises. I’ll start with Cars Assembly for Numbers.

2 Likes
28
1 Like
29

I’ve started drafting a PR for the cars assemble exercise:

3 Likes
30
2 Likes
31

This is still a draft:

I’m confused by Kotlin’s implementation of Unicode, with only codepoints up to 64k. This means, for example, that :heart: is fine, but :scream: is invalid.

Could someone who understands Unicode please cast a skeptical eye over it, to see if my write-up makes any sense?

Thanks!

1 Like
32

In case you wondered, these are all concepts I drafted over previous weeks. Today was just cleanup and submission.

33

I don’t know Kotlin, but if it uses UTF-16 (instead of UTF-8): both encodings can represent the same set of unicode characters.

While UTF-8 uses 1 to 4 bytes, UTF-16 uses 1 to 2 words (16-bit integers) - so 2 to 4 bytes.

You can check pages 33 to 38 of the current unicode standard.

1 Like
34

It seems Kotlin is strictly 2 bytes (not 1, not 4). Maybe an Android limitation? That’s not something I know about.

35

The culprit is JVM. On Kotlin/JVM, each char is a utf16 codepoint (token), not an actual character. That means :scream: does work, but will be two chars, namely \uD83D and \uDE31. Unfortunately grapheme support is not built-in in Java and therefore not in Kotlin.

In Java you’ll need something like BreakIterator. In JS you’ll use something like Intl.Segmenter. Kotlin does support multiple charsets, but that’s irrelevant. The underlying implementation is the 16-bit JVM char.

So that means that chars are, indeed, always 2 bytes (as expected), and unlike other languages iteration over a string’s chars will, like using a for loop to index over a string in JavaScript, grab the individual codepoints, instead of, as you may expect, the full grapheme.

Note that in JavaScript, it’s not that much better:

[...'🏳️‍🌈']
// => ['🏳', '️', '‍', '🌈']

'🏳️‍🌈'[0]
// => '\uD83C'

'🏳️‍🌈'[1]
// => '\uDFF3'

const segmenter = new Intl.Segmenter(undefined, { granularity: 'grapheme' });
[...segmenter.segment('🏳️‍🌈')].map(x => x.segment)
// => ['🏳️‍🌈'] (yay!)
3 Likes
36

Thanks for that explanation! It makes some sense now.

This destroyed my hopes that I could recycle the documents I wrote for Julia. That was confusing in its own way, but (I have to say) a more elegant and thorough implementation overall. It shows the perils of needing Java interop, I suppose - like any sort of backwards compatibility, it imposes design constraints.

2 Likes
37

Why do I have to reboot Win11 systems so often? At least partly because the file-locking mechanism (still in use!) was designed for DOS 1.0 - which assumed the files were on 360kB floppy disks, not the 2TB NVMe drives I now use as standard.

Please excuse me if I sound a bit sour…

Conversely, I’m now 69 and trying hard to show I’m not yet (entirely) obsolete!

3 Likes
38

Have you tried turning it off and on again?

3 Likes
39
2 Likes
40
1 Like