[Tutor] Python to non-Python

[Alan Gauld]

On 16/04/2023 01:44, ThreeBlindQuarks via Tutor wrote:
> I recently was asked to take some Python Code snippets and rewrite it in R. 

Translating a design between languages is always interesting, especially
if the languages have significant paradigm differences. Back in 1990 I
was involved in a networking project where we wrote a protocol
translator (X25 and TCP/IP to CMIP) in C, but using OOP style and a
bespoke extension library.

That translator is still running (and extended to several other
protocols with the original X25 long gone and CMIP replaced by SNMP!).
But in the intervening time the language has been moved from C to
C++(around 1994) then to Java (around 2001) then Python(in 2012) and I
recently heard they are now moving it to Rust. The basic design has
remained unchanged, most of the core classes and the architecture are
still there, but the language is radically different. But that's because
they translated between OOP languages. What would they have done if
asked to translate to, say Haskell? or Prolog?

In general, translating paradigms is the hard bit, translating language
features is usually straightforward.

> Questions often are asked why Python does not do something 
> that some language they learned earlier or know about. 

Yes, the desire for universal language features is often present in
learners, but once you know a dozen or more languages 9and 3 or 4
paradigms) you learn to just appreciate the new language for its own
features and not crave the past.

> Without explicit details, one barrier was the use of a common technique in Python:
> 
> first, second, third, last = f(args)
> 
> Would you believe quite a few other languages insist on returning only one thing 

I would say most languages. unpacking is quite a rare feature and I only
discovered it when I used Python. A few others have introduced it now
but its still rare (but a very useful shortcut)


> keywords
> CASE condition ~ return value,
> CASE condition ~ return value,

Select/Case/switch constructs are one of the areas where languages
differ most in the details. They are also one of the most fault prone
features in any language and one of the main things that OOP tries to
eliminate - use polymorphism instead its much more reliable and performant.


> As for the nested loops, I moved some into functions called 
> from the above so the overall outline is simpler.

One reason the protocol translator mentioned above has had such
a long run is that the design was explicitly done to a fairly
detailed level. The design is what gets ported between languages
not the code. Too many projects only have high level designs
that stop at class or even module-level structure but fail
to define the dynamics within the structure.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos