4 ms·

Serious question - why not just use python?

by lijok 3y ago

IshKebab 3y ago
Python would be a terrible choice for this. * It's been dragged into static typing kicking and screaming. * You import the whole Python infrastructure/packaging catastrophe. * It's not sandboxed. If you wanted something Python-like you would you Starlark.
- lijok 3y ago
  Which of these problems outweigh the complexity of onboarding a new language to an organization?
  - IshKebab 3y ago
    Probably the infrastructure/packaging mess. That's debatable. If you fix all of them though it's easily worth a new language, as long as it isn't too hard to learn. This looks very easy. I'd be more hesitant about Dhall or Nix (though obviously Nix comes with even bigger benefits so it might be worth the awkward language).
mikl 3y ago
Because (unless your app is written in Python) you don’t want to start a full-fledged Python run-time to read a config file. Nor do you want all the hassle of trying to ship a Python run-time with your application. Edit: and moreover, you probably do not want config files that can run arbitrary code with full access to the Python standard library.
bioballer 3y ago
Python isn't oriented around defining and validating data. For example, something like: "this number is be between 1 and 10" means you have to come up with a novel way to add validation, because it isn't built into the language. Also, Pkl is meant to be usable everywhere. General purpose languages tend to be tied to their own ecosystem--imagine telling a Go developer that they need to install Python, set up virtualenv, and run pip install so they can configure their application. We'd like Pkl to be a simple tool that can be brought anywhere, and easily integrated into any system.
- lijok 3y ago
  > For example, something like: "this number is be between 1 and 10" means you have to come up with a novel way to add validation, because it isn't built into the language. No need for a novel mechanism - there are plenty of available solutions to add validation to python > imagine telling a Go developer that they need to install Python Pkl doesn't come preinstalled on machines - so you'll have to install it as well > set up virtualenv, and run pip install so they can configure their application This is the real friction point, but is it a bigger friction point than having to adopt yet another DSL?
  - laserlight 3y ago
    > This is the real friction point, but is it a bigger friction point than having to adopt yet another DSL? Yesterday, I created a virtualenv, then ran `pip install`, only to see it fail. I found out that even `pip --version` was failing. I discovered that running `python -m ensurepip --upgrade` would fix pip. It did fix pip, but `pip install` still didn't work properly. I figured out that pip was reporting a different version of python than the one virtualenv is using. Running `python -m pip install --upgrade pip` upgraded pip, which should have been accomplished with the previous ensurepip command. Finally, everything was working properly. I experienced these problems after years of experience in python. To answer the question. Yes, it's worth adopting yet another DSL than using python.
    - lijok 3y ago
      Did you activate the virtual environment? For all the flak python gets, dependency setup is pretty simple if you're not flailing around aimlessly python3.12 -m venv --copies --clear --upgrade-deps ".venv" source ".venv/bin/activate" python -m pip install --upgrade pip setuptools wheel python -m pip install --editable .
      - laserlight 3y ago
        Yes, I had activated the virtual environment. Thanks for the guide. It works without problems. I had used `virtualenv venv -p /usr/local/bin/python3.12` in my setup. Yours seems to be a better way.

Serious question - why not just use python?

by lijok 3y ago

Serious question - why not just use python?

Python would be a terrible choice for this. * It's been dragged into static typing kicking and screaming. * You import the whole Python infrastructure/packaging catastrophe. * It's not sandboxed. If you wanted something Python-like you would you Starlark.

lijok 3y ago
Which of these problems outweigh the complexity of onboarding a new language to an organization?
- IshKebab 3y ago
  Probably the infrastructure/packaging mess. That's debatable. If you fix all of them though it's easily worth a new language, as long as it isn't too hard to learn. This looks very easy. I'd be more hesitant about Dhall or Nix (though obviously Nix comes with even bigger benefits so it might be worth the awkward language).

mikl 3y ago

Because (unless your app is written in Python) you don’t want to start a full-fledged Python run-time to read a config file. Nor do you want all the hassle of trying to ship a Python run-time with your application. Edit: and moreover, you probably do not want config files that can run arbitrary code with full access to the Python standard library.

bioballer 3y ago

Python isn't oriented around defining and validating data. For example, something like: "this number is be between 1 and 10" means you have to come up with a novel way to add validation, because it isn't built into the language. Also, Pkl is meant to be usable everywhere. General purpose languages tend to be tied to their own ecosystem--imagine telling a Go developer that they need to install Python, set up virtualenv, and run pip install so they can configure their application. We'd like Pkl to be a simple tool that can be brought anywhere, and easily integrated into any system.

lijok 3y ago
> For example, something like: "this number is be between 1 and 10" means you have to come up with a novel way to add validation, because it isn't built into the language. No need for a novel mechanism - there are plenty of available solutions to add validation to python > imagine telling a Go developer that they need to install Python Pkl doesn't come preinstalled on machines - so you'll have to install it as well > set up virtualenv, and run pip install so they can configure their application This is the real friction point, but is it a bigger friction point than having to adopt yet another DSL?
- laserlight 3y ago
  > This is the real friction point, but is it a bigger friction point than having to adopt yet another DSL? Yesterday, I created a virtualenv, then ran `pip install`, only to see it fail. I found out that even `pip --version` was failing. I discovered that running `python -m ensurepip --upgrade` would fix pip. It did fix pip, but `pip install` still didn't work properly. I figured out that pip was reporting a different version of python than the one virtualenv is using. Running `python -m pip install --upgrade pip` upgraded pip, which should have been accomplished with the previous ensurepip command. Finally, everything was working properly. I experienced these problems after years of experience in python. To answer the question. Yes, it's worth adopting yet another DSL than using python.
  - lijok 3y ago
    Did you activate the virtual environment? For all the flak python gets, dependency setup is pretty simple if you're not flailing around aimlessly python3.12 -m venv --copies --clear --upgrade-deps ".venv" source ".venv/bin/activate" python -m pip install --upgrade pip setuptools wheel python -m pip install --editable .
    - laserlight 3y ago
      Yes, I had activated the virtual environment. Thanks for the guide. It works without problems. I had used `virtualenv venv -p /usr/local/bin/python3.12` in my setup. Yours seems to be a better way.