4 ms·

How is the debugging experience? Is there a debugging experience? I'm currently a typescript user and I like what VS code has going on with attaching to chrom

How is the debugging experience? Is there a debugging experience? I'm currently a typescript user and I like what VS code has going on with attaching to chrome and providing debugging within the ide. Source maps are okay but a seamless experience in the source language is better. Does the kotlin IDE have facilities for debugging what is going on in the browser?

specialist 9y ago
Being a grumpy old man: it's not programming if I can't set a breakpoint.
- stevenwoo 9y ago
  I can remember having to debug some prototype hardware with LED's attached to address pins, you kids are spoiled these days! :)
- bitL 9y ago
  Talk to functional programming folks... :D
  - yawaramin 9y ago
    Or not, we do printf debugging ... :-)
  - droidist2 9y ago
    That's one reason I love Clojure, really nice tooling through IntelliJ + Cursive.
- askvictor 9y ago
  You've obviously never done embedded systems programming. Try debugging timing issues with a breakpoint.
  - bitL 9y ago
    Actually, how do you debug those? If you put in a breakpoint, use DTrace & co or do logger output, you won't likely hit the issue. I did this with super low-level distributed systems and they were mostly resolved by hard thinking and modeling execution path in my head...
    - tonyarkles 9y ago
      You've got the process figured out :) Reason through the code. Sometimes, reason through the output assembler (in case the C code is making invalid assumptions). Stare at oscilloscope traces. Think really hard about what's happening, come up with a hypothesis, and test that hypothesis. The hypothesis testing part is key. I've worked with embedded developers who "fix" a bug by making a code change, but can't at all explain why the change is likely to fix the bug. In many cases, the reason it seems to fix the bug is that it changes the timing just enough so that the bug happens less frequently, but without having a really solid causal explanation, it likely just means that it's going to be even harder to find the bug when it pops back up again.
    - askvictor 9y ago
      With great difficulty and annoyance. Once when developing with the 8051 family (using a development board that included a debugger), the program worked perfectly on the dev board, but when I burned it onto EEPROM, a subtle timing issue with a peripheral caused the program to fail. Much frustration ensued; had to develop that section with a long winded code->compile->burn->test cycle. Then we found out the particular 8051 variant we were using had been discontinued :(
  - specialist 9y ago
    Does Apple ][ 6502 assembler count?
hypnos_phi 9y ago
Sourcemaps work. If they doesn’t work, it‘s a bug
yaseenk 9y ago
You can debug javascript/typescript in IntelliJ but I think it’s an ultimate edition feature only.
prigara 9y ago
You can debug the app in IntelliJ IDEA (and in the browser) and put the breakpoints in the Kotlin code, thanks to the source maps. It's kind of similar to what you get when debugging TS in VS Code, WebStorm or IJ: the IDE will open Chrome and connect to it. But it's not possible to avoid source maps – to debug you still need to compile the app to JS to run in the browser.

specialist 9y ago

Being a grumpy old man: it's not programming if I can't set a breakpoint.

stevenwoo 9y ago
I can remember having to debug some prototype hardware with LED's attached to address pins, you kids are spoiled these days! :)
bitL 9y ago
Talk to functional programming folks... :D
- yawaramin 9y ago
  Or not, we do printf debugging ... :-)
- droidist2 9y ago
  That's one reason I love Clojure, really nice tooling through IntelliJ + Cursive.
askvictor 9y ago
You've obviously never done embedded systems programming. Try debugging timing issues with a breakpoint.
- bitL 9y ago
  Actually, how do you debug those? If you put in a breakpoint, use DTrace & co or do logger output, you won't likely hit the issue. I did this with super low-level distributed systems and they were mostly resolved by hard thinking and modeling execution path in my head...
  - tonyarkles 9y ago
    You've got the process figured out :) Reason through the code. Sometimes, reason through the output assembler (in case the C code is making invalid assumptions). Stare at oscilloscope traces. Think really hard about what's happening, come up with a hypothesis, and test that hypothesis. The hypothesis testing part is key. I've worked with embedded developers who "fix" a bug by making a code change, but can't at all explain why the change is likely to fix the bug. In many cases, the reason it seems to fix the bug is that it changes the timing just enough so that the bug happens less frequently, but without having a really solid causal explanation, it likely just means that it's going to be even harder to find the bug when it pops back up again.
  - askvictor 9y ago
    With great difficulty and annoyance. Once when developing with the 8051 family (using a development board that included a debugger), the program worked perfectly on the dev board, but when I burned it onto EEPROM, a subtle timing issue with a peripheral caused the program to fail. Much frustration ensued; had to develop that section with a long winded code->compile->burn->test cycle. Then we found out the particular 8051 variant we were using had been discontinued :(
- specialist 9y ago
  Does Apple ][ 6502 assembler count?

hypnos_phi 9y ago

Sourcemaps work. If they doesn’t work, it‘s a bug

yaseenk 9y ago

You can debug javascript/typescript in IntelliJ but I think it’s an ultimate edition feature only.

prigara 9y ago

You can debug the app in IntelliJ IDEA (and in the browser) and put the breakpoints in the Kotlin code, thanks to the source maps. It's kind of similar to what you get when debugging TS in VS Code, WebStorm or IJ: the IDE will open Chrome and connect to it. But it's not possible to avoid source maps – to debug you still need to compile the app to JS to run in the browser.