www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A little Go => Python story

reply "bearophile" <bearophileHUGS lycos.com> writes:
This blog post tells a short simple story of replacing Python 
with Go:

http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/2013/04/23/

Probably the SVM code was already written in C, and just called 
from Python. I don't know if later they have rewritten the SVM 
code in Go, I doubt this.


Its Reddit thread:

http://www.reddit.com/r/programming/comments/1cy3si/what_python_developers_need_to_know_before/

This story shows that it doesn't take a lot for some people to 
switch languages. Go is designed to appeal to Python coders, and 
this helps.
I think Go is simpler than D and this helps Python programmers 
that don't know a lot about the complexities of a system 
languages.

The blog post also lists many problems or troubles in converting 
Python code to Go, some of them apply as well to the converion of 
Python code to D (from this selection I have removed some silly 
things like "Go doesn't allow to have dict values of mixed 
types"):


* No built-in type for sets (have to use maps and test for 
existence)
* In absence of sets, have to write your own intersection, union 
etc. methods
* Python is more forgiving. You can take slices of strings using 
indexes that are out of range and it won't complain. You can take 
negative slices -- not Go.
* No unpacking of a tuple or list into separate variables (e.g. 
x,y,x = [1,2,3])
* Reading Go code is definitely more like a programming language 
whereas Python can be written as almost pseudocode. Go has more 
non-alphanumeric characters and uses || and && instead of "or" 
and "and".
* Writing to a file, there's File.Write([]byte) and 
File.WriteString(string) – a bit of a departure for Python 
developers who are used to the Python zen of having one way to do 
something
* If you're using JSON and your JSON is a mix of types, goooooood 
luck. You'll have to create a custom struct that matches the 
format of your JSON blob, and then Unmarshall the raw json into 
an instance of your custom struct. Much more work than just obj = 
json.loads(json_blob) like we're used to in Python land.


In the Reddit thread they also discuss a bit about a problem of 
Go dicts, but that problem is not present in D:


struct Foo {
     int bar, baz;
}

void main() {
     import std.stdio;
     Foo[string] a;

     a["hello"] = Foo(23, 42);
     writeln("a: hello = ", a["hello"]);
     a["hello"].bar = 0;
     writeln("a: hello = ", a["hello"]);
}


Bye,
bearophile
Apr 23 2013
next sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
The only one that seems "easy" to solve in D is adding sets, no?
Apr 23 2013
next sibling parent "Diggory" <diggsey googlemail.com> writes:
Perhaps you should be able to use void[T] for a set...
Apr 23 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Luís Marques:


 The only one that seems "easy" to solve in D is adding sets, no?


Considering the troubles given by the built-in D associative 
arrays, and the possibility to write good enough set literals 
like:

auto s1 = set([1, 10, 5]); // helper function.

Set!int items = iota(2, 11)
                 .map!(x => x % 10)
                 .set;

Then I think it's enough to add a Set!T in std.collections with 
the nice semantics of the Python sets, plus the set() helper.

Here the only limit is that D uses opCmp for all its comparisons, 
so some of the operators of the Python sets can't be defined, and 
they need to be only normal methods for the Set!T. I am not 
worried.

Bye,
bearophile
Apr 23 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Tuesday, 23 April 2013 at 23:09:46 UTC, bearophile wrote:


 * If you're using JSON and your JSON is a mix of types, 
 goooooood luck. You'll have to create a custom struct that 
 matches the format of your JSON blob, and then Unmarshall the 
 raw json into an instance of your custom struct. Much more work 
 than just obj = json.loads(json_blob) like we're used to in 
 Python land.


I think D already has this addressed, though maybe not with 
std.json.

obj = json.loads(json_blob)

to

obj = json.loads!MyType(json_blob)

Defining the type doesn't really seem the major problem with the 
Go approach.
Apr 23 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Sorry, the title of this thread should be "A little Python => Go 
story"...

Bye,
bearophile
Apr 23 2013
prev sibling parent "OlliP" <jeti789 web.de> writes:
I knew a little Go and then by chance had a look at Python. The 
similarities in syntax were striking. Because of the very quick 
build times, Go feels like a scripting language. However, it 
really falls short on OOP. Delegates in Go can mimic inheritance 
to some extend, but method overriding (aka virutal methods) 
remains impossible. I believe many Python/C++ developers won't 
pick Go due to its lack of OOP and more andvanced language 
features. Maybe as a scripting language or a languagee to write 
little tools or concurrent stuff.

I think just being a modernized C is not enough. Even in systems 
programming people look for more advanced language constructs as 
in C++ or D. If it's about performance alone, you would just 
stick to C. Currently Go can compete in performance just with 
Java. To define a business case in spite of the simplicity of the 
language IMHO speed would have been to be quite better as in Java.

Besides that thread multiplexing as in Go would also make a lot 
of sense in D. It already exists for Java (see 
http://hawtdispatch.fusesource.org/, 
https://github.com/lmax-exchange/disruptor). Maybe porting 
HawtDispatch to D can be done without having the approach in 
hatDispatch).

-- Oliver
Jun 23 2013