5 ms·

From the readme: > It's written in Python, so the code is short and easy to change. But we automatically translate it to C++ with custom tools, to make it fast

From the readme: > It's written in Python, so the code is short and easy to change. But we automatically translate it to C++ with custom tools, to make it fast and small. The deployed executable doesn't depend on Python. Why Python developers will do absolutely anything to work around the limitations of python but not use a different language.

nawgz 5y ago
> why python developers Isn’t it a perfectly understandable reason? We regularly pan C++ on here for its smorgasbord of implementation options for any given thing, and the complexity, customization, and fragility of a C++ code base always seems to be high especially for non experts in the domain. So, accordingly, people who know how to maintain code in a simpler and more flexible setup and can still convert to C++ for performance are taking a probable performance hit relative to “native” C++ (whatever that is in 2021), in order to maintain their tool with more ease. It’s very silly you move to slandering python developers and not contemplating the trade offs meaningfully
- DarkCrusader2 5y ago
  I am not sure how this is a slander. My point is, if python does not meet your performance/size/distribution requirements, choose something else instead of using "custom tools". Unless, compilation to other languages is supported as a first class feature by the language itself (for eg. the way Scala supports javascript and native binary), these work around are duct tapes to make Python do something it is not meant to do. Furthermore, there is no shortage of statically typed compiled languages to choose from. Go, Rust, Java(with GraalVM) or my recent favourite, Nim comes to mind.
  - nawgz 5y ago
    It is slander because you asked a question as if it was rhetorical when that actually had the easy answer that “the devs find Python to be the nicest C++ front end”, and again as I suggested it more or less seems to me that C++ front ends are all custom.
chubot 5y ago
http://www.oilshell.org/blog/2019/06/17.html#why-is-it-written-in-python http://www.oilshell.org/blog/2019/06/17.html#why-is-it-writt...
godDLL 5y ago
Python is a very sound environment, with fantastic libraries and documentation. The tooling is superb. The resulting code is poetry, readable and expressive. I personally have moved on to a Nim + Lua combo (depending on use case), because I can see your point. But I will always love Python.
- DarkCrusader2 5y ago
  Agree with you there, except the tooling part. I still don't love the dependency management having gone through pip/venv, conda, pipenv, poetry, ?? over the years. Everything else is fantastic with excellent community. I too am looking into nim more and more recently because I don't want to write code without static typing anymore and it has very nice syntax and native compilation.
  - godDLL 5y ago
    The depend mgmt part is like that because people have different wants. There are DevOps wants, system packager wants, user wants and coder wants. And they are somewhat orthogonal, but not entirely. Each of the tools you mention have their good part wrt/ one of those four categories, and the rest is an afterthought. They did not end up doing one thing well, but one thing well and the other three too. Not as well. The way, or one way to change that would be to borrow the overall idea and semantics from each "good" implementation, but to limit it to just that; and build four separate projects under one community, so that there is pollination of knowledge and efforts, but no cross-contamination of goals and semantics. I'm not sure I am the person to start something like that.

nawgz 5y ago

> why python developers Isn’t it a perfectly understandable reason? We regularly pan C++ on here for its smorgasbord of implementation options for any given thing, and the complexity, customization, and fragility of a C++ code base always seems to be high especially for non experts in the domain. So, accordingly, people who know how to maintain code in a simpler and more flexible setup and can still convert to C++ for performance are taking a probable performance hit relative to “native” C++ (whatever that is in 2021), in order to maintain their tool with more ease. It’s very silly you move to slandering python developers and not contemplating the trade offs meaningfully

DarkCrusader2 5y ago
I am not sure how this is a slander. My point is, if python does not meet your performance/size/distribution requirements, choose something else instead of using "custom tools". Unless, compilation to other languages is supported as a first class feature by the language itself (for eg. the way Scala supports javascript and native binary), these work around are duct tapes to make Python do something it is not meant to do. Furthermore, there is no shortage of statically typed compiled languages to choose from. Go, Rust, Java(with GraalVM) or my recent favourite, Nim comes to mind.
- nawgz 5y ago
  It is slander because you asked a question as if it was rhetorical when that actually had the easy answer that “the devs find Python to be the nicest C++ front end”, and again as I suggested it more or less seems to me that C++ front ends are all custom.

chubot 5y ago

http://www.oilshell.org/blog/2019/06/17.html#why-is-it-written-in-python http://www.oilshell.org/blog/2019/06/17.html#why-is-it-writt...

godDLL 5y ago

Python is a very sound environment, with fantastic libraries and documentation. The tooling is superb. The resulting code is poetry, readable and expressive. I personally have moved on to a Nim + Lua combo (depending on use case), because I can see your point. But I will always love Python.

DarkCrusader2 5y ago
Agree with you there, except the tooling part. I still don't love the dependency management having gone through pip/venv, conda, pipenv, poetry, ?? over the years. Everything else is fantastic with excellent community. I too am looking into nim more and more recently because I don't want to write code without static typing anymore and it has very nice syntax and native compilation.
- godDLL 5y ago
  The depend mgmt part is like that because people have different wants. There are DevOps wants, system packager wants, user wants and coder wants. And they are somewhat orthogonal, but not entirely. Each of the tools you mention have their good part wrt/ one of those four categories, and the rest is an afterthought. They did not end up doing one thing well, but one thing well and the other three too. Not as well. The way, or one way to change that would be to borrow the overall idea and semantics from each "good" implementation, but to limit it to just that; and build four separate projects under one community, so that there is pollination of knowledge and efforts, but no cross-contamination of goals and semantics. I'm not sure I am the person to start something like that.