Live data from Hacker News

Why People Should Learn Python

iluxonchik.github.io

321–329 of 329 posts

Re: Why People Should Learn Python

#321
post #319

Earlier quoted context omitted.

> Groovy needs two lines (@Grab and import) to get a dependency. Golang only requires the import. Perhaps Groovy needs to be rewritten in Go. I'm not dissing Golang but it isn't even remotely the same. A major portion of the OP content was about using Python instead of shell scripts. Golang is not scripting language. You need to compile for each platform and the code is opaque once it is compiled. Not to mention Gola…

> I'm not sure if you just mistyped I didn't mistype. Go would make a good language for writing dynamic languages such as Apache Groovy in. My own Gro is just one example of such a dynamic language.

> Go would make a good language for writing dynamic languages such as Apache Groovy in

Wasn't the whole point of Groovy to have something Ruby-like that was more intimately tied into the JVM ecosystem? Seems to me that Go would be just about the worst imaginable [0] implementation language for that.

[0] Or at least, in the class of extremely poor choices that includes all languages that are not themselves especially targeted to the JVM platform.

Re: Why People Should Learn Python

#323
post #319

Earlier quoted context omitted.

> Groovy needs two lines (@Grab and import) to get a dependency. Golang only requires the import. Perhaps Groovy needs to be rewritten in Go. I'm not dissing Golang but it isn't even remotely the same. A major portion of the OP content was about using Python instead of shell scripts. Golang is not scripting language. You need to compile for each platform and the code is opaque once it is compiled. Not to mention Gola…

> I'm not sure if you just mistyped I didn't mistype. Go would make a good language for writing dynamic languages such as Apache Groovy in. My own Gro is just one example of such a dynamic language.

Yes I think I realize your point. But original it came across though like:

"oh your script can just be rewritten in Go and while we are at it Groovy should be rewritten in Go".

But yeah I would be interested in platform agnostic scripting language with out GIL, cheap threads, easy dependency access. I'll keep Gro on my radar :)

Are you going to change your middle name now to "Gro" (I did find that amusing albeit I'm not sure I know your entire history with Groovy)?

Re: Why People Should Learn Python

#324
post #319

Earlier quoted context omitted.

> I'm not sure if you just mistyped I didn't mistype. Go would make a good language for writing dynamic languages such as Apache Groovy in. My own Gro is just one example of such a dynamic language.

> Go would make a good language for writing dynamic languages such as Apache Groovy in Wasn't the whole point of Groovy to have something Ruby-like that was more intimately tied into the JVM ecosystem? Seems to me that Go would be just about the worst imaginable [0] implementation language for that. [0] Or at least, in the class of extremely poor choices that includes all languages that are not themselves especially…

I think his point was instead of using the JVM runtime to now use the Go lang runtime. Of course you would need the interpreter for each platform like Python does but Go has a unique runtime. I'm not sure how dynamic it is but you can certainly run a scripting language in it and make it easy to access other Go stuff.

I'm not sure how easy it would be to access ad-hoc libraries without recompile though since Go doesn't really have dynamic loading of libraries (or maybe it does now?).

Little tangental ... After reading his blog I'm a little concerned though that the dude (Gavin) has spent an enormous effort defending his stance on how poorly the Groovy organization is... I'm not saying his wrong but is almost obsessive and a waste of energy.

Re: Why People Should Learn Python

#325

Earlier quoted context omitted.

> Go would make a good language for writing dynamic languages such as Apache Groovy in Wasn't the whole point of Groovy to have something Ruby-like that was more intimately tied into the JVM ecosystem? Seems to me that Go would be just about the worst imaginable [0] implementation language for that. [0] Or at least, in the class of extremely poor choices that includes all languages that are not themselves especially…

I think his point was instead of using the JVM runtime to now use the Go lang runtime. Of course you would need the interpreter for each platform like Python does but Go has a unique runtime. I'm not sure how dynamic it is but you can certainly run a scripting language in it and make it easy to access other Go stuff. I'm not sure how easy it would be to access ad-hoc libraries without recompile though since Go doesn'…

> I think his point was instead of using the JVM runtime to now use the Go lang runtime.

Right, my point was that a central part of the point of Groovy was being for the JVM, it wasn't a language in search of a runtime.

So, while there might be an argument that a language like Groovy for Go runtime might be useful (I'm somewhat unconvinced of that), it just seems not to be the case that Go is a good choice for a language such as Groovy (that is, it is not the case that Groovy is an example of a language for which it would make sense to use Go as the implementation language.)

Re: Why People Should Learn Python

#326
post #198

Python is so easy to write, use and read, I would not understand how a programmer would not know it already. It literally has everything you want in a language. Granted, it's not on-the-metal fast, and it still has some gimmicks, like variables behaving like pointers or references (which can be a little awkward), but still, python is the language of the decade.

Ugh. I tell you, I keep trying to pick it up because I hear so much about it. However, when I code in it I feel completely uninspired. I can only get so far into a book or tutorial before my eyes glaze over and I'm thinking about something else. I think when I code, I want to own the machine, not just skate on the surface. Python doesn't even crank my engine the way BASIC did years ago. I also think part of my proble…

Well python is not for solving hard problems. If you want to own the machine you need C++ or C.

Python is a language that makes programming easy. That's a lot.

Re: Why People Should Learn Python

#327

Earlier quoted context omitted.

Maven Central says it's around 4.4MB (with some things still pending to be dropped before the release of the final version)[1]. [1] https://mvnrepository.com/artifact/org.scala-lang/scala-libr... I would disagree with the comment on verbosity compared to Java 8/Haskell/Ocaml. Most of the things I do regularly in Scala would require a magnitude of more code. Ocaml doesn't even have higher-kinded types or implicits, so…

I'm not sure I like implicits as for HKT... "with great power comes...". HKTs are great for a generic library writer (aka standard library) but I think the over abstract nature ends up confusing your average developer. You basically have your type aficionados obfuscating the codebase for developers who can barely handle generics. It is sort of analogous to using massive reflection / meta-programming in scripting lang…

> I'm not sure I like implicits

I think they're a necessary evil. I need extension methods, ad-hoc polymorphism, and a way to use ad-hoc polymorphism while still writing nice DSLs (i.e. what spray calls the magnet pattern). I'm nervous about implicits, but I haven't seen a better solution.

> HKTs are great for a generic library writer (aka standard library) but I think the over abstract nature ends up confusing your average developer.

There are few things more frustrating than having to copy-paste because your language can't handle the abstraction. There are less cases where you need HKTs than where you need basic generics, sure, but sooner or later you do need them. And since everyone hates copy-paste, they end up using annotations or reflection or string-based templating to generate code, all of which end up more confusing to the average developer. At least with HKTs you still have ordinary values that follow the rules of the language, rather than wondering whether you can still factor out a common method because it's called from an annotated method and an unannotated method, and what annotations you need to put on it to make that work.

> I vaguely remember HKTs being expensive compile time. Is that still the case?

HKTs per se are not expensive. Type inference in the presence of HKTs can be expensive (though note that even in OCaml or pure ML there are pathological cases for type inference - http://cs.stackexchange.com/questions/6617/concise-example-o... ). Scala implicit resolution can be expensive especially when used with recursion; global-uniqueness constraints a la Haskell typeclasses would be one solution, but arguably introduce more trouble than they're worth. One way or another, Scala compilation ends up being pretty slow, which is unfortunate.

Re: Why People Should Learn Python

#328

Earlier quoted context omitted.

The second annoyance is that you need to write __init__ methods quite often. Correct me if I'm wrong, but there doesn't seem to be built-in support in Python for having attributes initialized by the the constructor. For example in Perl 6, I can write class Point { has $.x; has $.y; } ... and I get a constructor Pair.new(x => 1, y => 42) for free, no need to write custom initializers.

Nothing built in, and generally not recommended, but you can do it! If you want to be really flexible and just allow any attribute, you can do this: class Foo: def __init__(self, *args, **kwargs): self.__dict__.update(**kwargs) And it will automatically assign any keyword arguments you use as attributes to the object. For example `foo = Foo(name='Bob', age=99)` If you still want to keep a strict list of allowed attri…

I believe you could also accomplish this with a metaclass, as well.

Re: Why People Should Learn Python

#329

Earlier quoted context omitted.

> Go would make a good language for writing dynamic languages such as Apache Groovy in Wasn't the whole point of Groovy to have something Ruby-like that was more intimately tied into the JVM ecosystem? Seems to me that Go would be just about the worst imaginable [0] implementation language for that. [0] Or at least, in the class of extremely poor choices that includes all languages that are not themselves especially…

I think his point was instead of using the JVM runtime to now use the Go lang runtime. Of course you would need the interpreter for each platform like Python does but Go has a unique runtime. I'm not sure how dynamic it is but you can certainly run a scripting language in it and make it easy to access other Go stuff. I'm not sure how easy it would be to access ad-hoc libraries without recompile though since Go doesn'…

> to access ad-hoc libraries without recompile though since Go doesn't really have dynamic loading of libraries

In the current version of Gro, I recompile (just like "go run"), so there's a 1 second lag even for simple scripts. For the same reason, the very basic REPL provided has a 1-second process time for each command. There's talk on reddit.com/r/golang about building a VM for Go so maybe in future Gro can use those.

> Are you going to change your middle name now to "Gro"

"Gro" is short for the "Grover edition of the Groovy language".

> has spent an enormous effort defending his stance on how poorly the Groovy organization is... [...] almost obsessive and a waste of energy

I've averaged a blog entry a month for the last 5 years. It seems like enormous effort and obsessive to you because you saw them all at once.

Post reply on HN