4 ms·
I don't try it yet but it remember me Groovy type system. It is a great feature. No type checker was one of the bigger flaws in Python. When in Groovy, I use
by azaras 10y ago
I don't try it yet but it remember me Groovy type system. It is a great feature.
No type checker was one of the bigger flaws in Python.
When in Groovy, I use type checker in public functions and APIs. It is a good communication tool.
In my opinion, Python is better than Groovy. This feature still make it better.
- networked 10y agoI've used Python a lot more than Groovy but one thing I find myself missing from Python and other scripting languages since I discovered Groovy is the ability for a standalone script to retrieve its dependencies on startup. What this means is that if you put @Grab(group='foo', module='bar', version='1.0.0') at the top of randomscript.groovy you will have bar available to import by the time the script starts.
- azaras 10y agoYou could use: import pip pip.main(['install', 'bar'])
- jonesetc 10y agoPlease don't though.
- networked 10y agoIt's not this simple. That code will only work if you are root or in a virtualenv — and having to create a virtualenv manually contradicts the idea of a self-contained, standalone script that manages dependencies on its own. To install bar as a non-root user you will have to do import pip pip.main(['install', '--user', 'bar']) which throws an error, e.g., if bar is already installed, meaning you will have to wrap the calls to pip.main() in a "try" block and differentiate between the types of errors they throw. The above already makes it noticably less convenient for a script to manage its own dependencies. The killing blow, however, comes form the fact that pip won't let you install multiple versions of the same package in parallel: the most recently installed version overwrites the previous one. This means that a script that relies on a per-user package store can only be safe if it checks the version of every package it uses and replaces it if needed each time it is run. This can a take a long time and is error prone (what if your Internet connection goes down?) but the alternative is simply to deal with the brittleness. I can see this being solved for Python but the solution will probably involve automatically creating and caching per-script virtualenvs. For now, though, something like PyInstaller (i.e., binaries) remains more practical if you want to distribute standalone Python scripts.
- azaras 10y agoI am sorry I made a mistake. You are right. Thanks for the explanation.
- networked 10y agoNo worries!
- raiph 10y agoAiui Perl6's module related design elements allow for this though I don't know if anyone has implemented what you describe. I'll be happy to discuss this further if anyone shows interest.
- seanp2k2 10y agoYou might enjoy Go
- vorg 10y agoApache Groovy's original use case was scripting, so there's many features like that which makes Groovy be Bash for the JVM. It was based on Beanshell originally, but with closures and collections syntax added. Just don't try building any actual systems with Groovy -- do that in a language designed from the ground up for performance, e.g. Java, Scala, or Kotlin.
- networked 10y agos/missing from Python/missing in Python/
- lmm 10y agoYou might like to look at Scala. You can write in a very similar style to Groovy or Python, but you get a full first-class type system. Everything's checked, but with type inference so it rarely gets in the way if you don't want to write any types.
- azaras 10y agoMy problem with Scala is that it is more complicated than Python. I like Python simplicity.
- airless_bar 10y agoNot sure Python is simpler ... except maybe "easier" to move should-be-compile-time failures to run-time. :-)
- jquast 10y agoonly wish the tooling, such as sbt, were not so lackluster. python as a first language? no problem. scala as a first language? you've got to be kidding me...