6 ms·

Transpiled should be treated separately from ported. This sort of code isn't readable, idiomatic nor maintainable. https://gitlab.com/cznic/tcl/-/blob/master/

by vkaku 4y ago

Transpiled should be treated separately from ported. This sort of code isn't readable, idiomatic nor maintainable. https://gitlab.com/cznic/tcl/-/blob/master/lib/capi_windows_amd64.go https://gitlab.com/cznic/tcl/-/blob/master/lib/capi_windows_...

zasdffaa 4y ago
ISWYM but > This sort of code isn't readable, idiomatic nor maintainable isn't really fair. The original code is hopefully readable, idiomatic and maintainable, and if the transpiler does a correct job, who cares about the output any more than I care about the ugliness of the ASM in my object code when I compile it from source.
- AlecSchueler 4y ago
  It seems fair to me. They only said that it should be seen as something separate than a port, not that it was bad. Honestly I think you're both right. Yes, it's true that it doesn't matter if you only want to get the code running in a Go environment for whatever reason. But anyone wanting to learn about TCL or idiomatic Go by reading the source code for this project will be disappointed, and that struck me as the main appeal of this when I saw the headline.
randomdata 4y ago
If a program was classically built for x86 and was ported to ARM, the compiled output wouldn’t be any more readable. I’m not sure transpiled, which is just compiled by another name, is significant.
- masklinn 4y ago
  The point of GP is to differentiate porting from compiling, whether you call that compiled or transpiled is immaterial, the goal is to differentiate between a codebase which is idiomatic, understandable, and maintainable, and one which is a compiler artefact. A port would imply and independent maintenance. Here you wouldn't maintain that codebase, instead you'd fix the upstream or the compiler, and recompile.
  - randomdata 4y ago
    > A port would imply and independent maintenance. Quite the opposite. Port refers to targeting a different environment using the same codebase. The aforementioned ARM port wouldn't require a new codebase to maintain, but rather a new/modified compiler to target the ARM environment. Similarly, a macOS port of Linux software wouldn't require maintaining another codebase, it would require changing the compiler to support a macOS target. > Here you wouldn't maintain that codebase, instead you'd fix the upstream or the compiler, and recompile. Exactly. In this case a different compiler that targets the Go environment has been introduced. That does not imply that the compiled output is what should be maintained going forward. You wouldn't maintain the product of an ARM port or macOS port either. It is a port, not a fork. Fork is the word we use when there is implication of independent maintenance.
    - oriolid 4y ago
      These are rather unusual definitions. Where I come from, porting to a new platform would mean rewriting platform-specific parts of the app, not coming up with a compiler that magically supports both targets. The choice between forking and refactoring the app into shared and platform-specific modules depends on many factors. Though I'd really like to see a compiler, not wrapper library, that supports both Apple's Core Whatever and your choice of Linux libraries. On extreme end, porting something from let's say Commodore 64 to Spectrum ZX would be more a complete rewrite. I also don't really understand the point of this project. Since it's compiled from C, it doesn't get any of possible benefits of using a language that is not C.
      - randomdata 4y ago
        > porting to a new platform would mean rewriting platform-specific parts of the app That may be part of the process, sure. The formal definition isn't clear on exactly what process is necessary to target a new environment, just that some action is necessary. Introducing a new compiler is one possible action to achieve the result. However, when you do have to modify the code like you suggest, typically you are adding the environment specific aspects in #ifdef-type directives, so you're still not introducing a new codebase to maintain. It's still the same codebase that will be maintained just as it always way. And even if you want to split hairs, no matter how you slice it there is no implication that the product of the port is what you will maintain. I still have no idea where that is coming from. > I also don't really understand the point of this project. To avoid cgo when using the library, I'm sure. Isn't that the point of a lot of cznic/modernc.org's projects?
compsciphd 4y ago
well it gives a lower bound on port performance.
bheadmaster 4y ago
I agree - scrolling through the codebase, I see a lot of unsafe.Pointer usage, which is rarely used in idiomatic Go, and throws a good part of static analysis through the window. So all the bugs in C code would also be in Go code - or might even be worse because of different runtime.

by vkaku 4y ago

zasdffaa 4y ago

ISWYM but > This sort of code isn't readable, idiomatic nor maintainable isn't really fair. The original code is hopefully readable, idiomatic and maintainable, and if the transpiler does a correct job, who cares about the output any more than I care about the ugliness of the ASM in my object code when I compile it from source.

AlecSchueler 4y ago
It seems fair to me. They only said that it should be seen as something separate than a port, not that it was bad. Honestly I think you're both right. Yes, it's true that it doesn't matter if you only want to get the code running in a Go environment for whatever reason. But anyone wanting to learn about TCL or idiomatic Go by reading the source code for this project will be disappointed, and that struck me as the main appeal of this when I saw the headline.

randomdata 4y ago

If a program was classically built for x86 and was ported to ARM, the compiled output wouldn’t be any more readable. I’m not sure transpiled, which is just compiled by another name, is significant.

masklinn 4y ago
The point of GP is to differentiate porting from compiling, whether you call that compiled or transpiled is immaterial, the goal is to differentiate between a codebase which is idiomatic, understandable, and maintainable, and one which is a compiler artefact. A port would imply and independent maintenance. Here you wouldn't maintain that codebase, instead you'd fix the upstream or the compiler, and recompile.
- randomdata 4y ago
  > A port would imply and independent maintenance. Quite the opposite. Port refers to targeting a different environment using the same codebase. The aforementioned ARM port wouldn't require a new codebase to maintain, but rather a new/modified compiler to target the ARM environment. Similarly, a macOS port of Linux software wouldn't require maintaining another codebase, it would require changing the compiler to support a macOS target. > Here you wouldn't maintain that codebase, instead you'd fix the upstream or the compiler, and recompile. Exactly. In this case a different compiler that targets the Go environment has been introduced. That does not imply that the compiled output is what should be maintained going forward. You wouldn't maintain the product of an ARM port or macOS port either. It is a port, not a fork. Fork is the word we use when there is implication of independent maintenance.
  - oriolid 4y ago
    These are rather unusual definitions. Where I come from, porting to a new platform would mean rewriting platform-specific parts of the app, not coming up with a compiler that magically supports both targets. The choice between forking and refactoring the app into shared and platform-specific modules depends on many factors. Though I'd really like to see a compiler, not wrapper library, that supports both Apple's Core Whatever and your choice of Linux libraries. On extreme end, porting something from let's say Commodore 64 to Spectrum ZX would be more a complete rewrite. I also don't really understand the point of this project. Since it's compiled from C, it doesn't get any of possible benefits of using a language that is not C.
    - randomdata 4y ago
      > porting to a new platform would mean rewriting platform-specific parts of the app That may be part of the process, sure. The formal definition isn't clear on exactly what process is necessary to target a new environment, just that some action is necessary. Introducing a new compiler is one possible action to achieve the result. However, when you do have to modify the code like you suggest, typically you are adding the environment specific aspects in #ifdef-type directives, so you're still not introducing a new codebase to maintain. It's still the same codebase that will be maintained just as it always way. And even if you want to split hairs, no matter how you slice it there is no implication that the product of the port is what you will maintain. I still have no idea where that is coming from. > I also don't really understand the point of this project. To avoid cgo when using the library, I'm sure. Isn't that the point of a lot of cznic/modernc.org's projects?

compsciphd 4y ago

well it gives a lower bound on port performance.

bheadmaster 4y ago

I agree - scrolling through the codebase, I see a lot of unsafe.Pointer usage, which is rarely used in idiomatic Go, and throws a good part of static analysis through the window. So all the bugs in C code would also be in Go code - or might even be worse because of different runtime.