Re: What is acceptable as 'open-source'? [was Python vs C++]
Chris Angelico ros...@gmail.com wrote in message news:captjjmp_jfxth_l6us30gbotmbyhw_imu-pjdglevgj2nut...@mail.gmail.com... On Wed, Aug 27, 2014 at 5:50 PM, Frank Millman fr...@chagford.com wrote: This is quite a timely message for me. I am inching closer to releasing a version of my accounting software, and a lot of the above comments apply to me as well. At present I am the only developer, and my project is not hosted anywhere, so I have to decide how to make it available, and I am open to suggestions. [...] Go public first, and watch what people get confused at - then document those parts. If you try to document everything first, you'll spend heaps of time and effort on it, and maybe won't even be happy with the result. I *think* I have created a project on GitHub and uploaded my software there. It is called AccInABox. This name probably needs a bit of explanation. Acc is an accountant. Box is the computer. You can set the system up with various rules and parameters, and then leave your staff to operate it without supervision. The program acts as your accountant, and will control what the staff can and cannot do. At the last count, there are about 10 million things I still have to do before it is a working product. But the structure feels quite stable now, and you can do a few simple things with it, so I am ready for people to have a look and offer feedback. I don't know GitHub at all, and I don't know what other information you need, so please let me know whether it works. Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: What is acceptable as 'open-source'? [was Python vs C++]
On Thu, Aug 28, 2014 at 11:44 PM, Frank Millman fr...@chagford.com wrote: I *think* I have created a project on GitHub and uploaded my software there. It is called AccInABox. https://github.com/FrankMillman/AccInABox Seems to be all there! You seem to have a default README.md as well as your README that has real content in it. If you delete README.md, the other one should become visible on the main project page. I'll shoot through a PR for that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Tue, Aug 26, 2014 at 11:43 PM, alex23 wuwe...@gmail.com wrote: On 26/08/2014 6:12 PM, Amirouche Boubekki wrote: 2014-08-26 6:02 GMT+02:00 Ian Kelly ian.g.ke...@gmail.com mailto:ian.g.ke...@gmail.com: It would be just as easy or easier in Python, or one could save a lot more effort by just using RPG Maker like every other indie RPG developer seems to do. I don't think there is FLOSS equivalent. There is indeed: http://openrpgmaker.sourceforge.net/ Ugh. There seems to be no public repository, and the only source to be found is from release-versioned tarballs, so there's apparently no collaboration other than some forums for reporting bugs and requesting features. All the work is done by one developer in his spare time, and he is currently on hiatus since April. Meanwhile the most recent release is February, so it's not like somebody could just pick it up and start hacking and expect to merge. That's only open-source under the most literal of definitions. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Wed, Aug 27, 2014 at 12:23 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Tue, Aug 26, 2014 at 11:43 PM, alex23 wuwe...@gmail.com wrote: On 26/08/2014 6:12 PM, Amirouche Boubekki wrote: 2014-08-26 6:02 GMT+02:00 Ian Kelly ian.g.ke...@gmail.com mailto:ian.g.ke...@gmail.com: It would be just as easy or easier in Python, or one could save a lot more effort by just using RPG Maker like every other indie RPG developer seems to do. I don't think there is FLOSS equivalent. There is indeed: http://openrpgmaker.sourceforge.net/ Ugh. There seems to be no public repository, and the only source to be found is from release-versioned tarballs, so there's apparently no collaboration other than some forums for reporting bugs and requesting features. All the work is done by one developer in his spare time, and he is currently on hiatus since April. Meanwhile the most recent release is February, so it's not like somebody could just pick it up and start hacking and expect to merge. That's only open-source under the most literal of definitions. And the license is GPL, which I think is an unfortunate choice for a game maker, since it probably means that any games developed using it must themselves be distributed libre and open-source. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Tue, Aug 26, 2014 at 2:12 AM, Amirouche Boubekki amirouche.boube...@gmail.com wrote: 2014-08-26 6:02 GMT+02:00 Ian Kelly ian.g.ke...@gmail.com: On Mon, Aug 25, 2014 at 4:52 AM, Amirouche Boubekki amirouche.boube...@gmail.com wrote: - I am a big fan of Final Fantasy games, it seems to be an easy game experience to code Maybe not so easy, if the horrifying number of bugs in the early games of the series are any indication. I started with FF VII, I don't remember any bugs. Ah, well, that's about when they seem to have gotten their act together with QA. The first and sixth games in particular had some rather notorious game-breaking bugs. I think it says something about the appeal of the series that those were two of the most beloved entries despite all the bugs. -- https://mail.python.org/mailman/listinfo/python-list
Re: What is acceptable as 'open-source'? [was Python vs C++]
Ian Kelly ian.g.ke...@gmail.com wrote in message news:calwzidkro_hryamwxbk0go-w1oj6ty6myb_c5vhxb6okgol...@mail.gmail.com... Ugh. There seems to be no public repository, and the only source to be found is from release-versioned tarballs, so there's apparently no collaboration other than some forums for reporting bugs and requesting features. All the work is done by one developer in his spare time, and he is currently on hiatus since April. Meanwhile the most recent release is February, so it's not like somebody could just pick it up and start hacking and expect to merge. That's only open-source under the most literal of definitions. This is quite a timely message for me. I am inching closer to releasing a version of my accounting software, and a lot of the above comments apply to me as well. At present I am the only developer, and my project is not hosted anywhere, so I have to decide how to make it available, and I am open to suggestions. I have had two attempts at running an hg repository locally, and I am afraid that I am not keeping it up to date. I do have a master copy, but I have made so many changes in my clone that a merge will not make any sense, so I will have to start afresh. I think that making it public will be the only way that I can force myself to update it regularly. I could stick to hg (or git) but I have recently come across fossil, and it seems ideal for my needs. Has anyone used it? It seems to have everything it needs (a wiki and a ticketing system) for self-hosting, and I have my own domain that I have not activated yet, so maybe I should just use fossil and host it myself. Any comments? There is no test suite (shock, horror). I have not got my head around that yet. The things that I could write tests for are so trivial that they don't seem worth the effort, and the things that cause me problems are so complex, because they depend on exactly what features have been activated, that the permutations are endless and I don't know where to start. However, once it is public, if someone is prepared to do a bit of mentoring, I will start to fill the gap. Documentation is a mess. I did start using Sphinx a while ago, so there is a sprinkling of rest-format docstrings, but they have not been kept up-to-date, and in some cases are out of date. There are plenty of other comments in the code, mostly reminders to myself about various issues. I don't know open-source etiquette. Should I spend the time to sort this out before going public, or is it acceptable to leave it as is for now? Any other comments? Frank Millman -- https://mail.python.org/mailman/listinfo/python-list
Re: What is acceptable as 'open-source'? [was Python vs C++]
On Wed, Aug 27, 2014 at 5:50 PM, Frank Millman fr...@chagford.com wrote: This is quite a timely message for me. I am inching closer to releasing a version of my accounting software, and a lot of the above comments apply to me as well. At present I am the only developer, and my project is not hosted anywhere, so I have to decide how to make it available, and I am open to suggestions. I have had two attempts at running an hg repository locally, and I am afraid that I am not keeping it up to date. I do have a master copy, but I have made so many changes in my clone that a merge will not make any sense, so I will have to start afresh. I think that making it public will be the only way that I can force myself to update it regularly. Then you need to develop a new style of working, which plays more nicely with source control. Instead of hacking on whatever you feel like doing and then committing to source control later, make each change and immediately commit it. Get into the habit of putting useful commit messages onto your changes. As you say, making it public will help you force yourself to keep that up-to-date. I could stick to hg (or git) but I have recently come across fossil, and it seems ideal for my needs. Has anyone used it? It seems to have everything it needs (a wiki and a ticketing system) for self-hosting, and I have my own domain that I have not activated yet, so maybe I should just use fossil and host it myself. Any comments? I haven't used fossil personally, but I'm not really a fan of all-in-one systems; they're somewhat inflexible. If you don't like the wiki, you're stuck with it. I'd rather work with all the parts separately - change one and it doesn't affect anything else. But if all fossil's parts suit you, then by all means, use it! Documentation is a mess. I did start using Sphinx a while ago, so there is a sprinkling of rest-format docstrings, but they have not been kept up-to-date, and in some cases are out of date. There are plenty of other comments in the code, mostly reminders to myself about various issues. I don't know open-source etiquette. Should I spend the time to sort this out before going public, or is it acceptable to leave it as is for now? Go public first, and watch what people get confused at - then document those parts. If you try to document everything first, you'll spend heaps of time and effort on it, and maybe won't even be happy with the result. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: What is acceptable as 'open-source'? [was Python vs C++]
On 8/27/14 3:50 AM, Frank Millman wrote: Ian Kelly ian.g.ke...@gmail.com wrote in message news:calwzidkro_hryamwxbk0go-w1oj6ty6myb_c5vhxb6okgol...@mail.gmail.com... Ugh. There seems to be no public repository, and the only source to be found is from release-versioned tarballs, so there's apparently no collaboration other than some forums for reporting bugs and requesting features. All the work is done by one developer in his spare time, and he is currently on hiatus since April. Meanwhile the most recent release is February, so it's not like somebody could just pick it up and start hacking and expect to merge. That's only open-source under the most literal of definitions. This is quite a timely message for me. I am inching closer to releasing a version of my accounting software, and a lot of the above comments apply to me as well. At present I am the only developer, and my project is not hosted anywhere, so I have to decide how to make it available, and I am open to suggestions. I have had two attempts at running an hg repository locally, and I am afraid that I am not keeping it up to date. I do have a master copy, but I have made so many changes in my clone that a merge will not make any sense, so I will have to start afresh. I think that making it public will be the only way that I can force myself to update it regularly. You don't need a local hg repo, you just need a working tree. I recommend choosing either hg or git, and then using BitBucket or Github, and being done with it. I could stick to hg (or git) but I have recently come across fossil, and it seems ideal for my needs. Has anyone used it? It seems to have everything it needs (a wiki and a ticketing system) for self-hosting, and I have my own domain that I have not activated yet, so maybe I should just use fossil and host it myself. Any comments? Fossil is one of those technologies that is very attractive in and of itself, but is so under-adopted that it will itself be a barrier to collaboration. (Frankly, hg is getting to that category also.) There is no test suite (shock, horror). I have not got my head around that yet. The things that I could write tests for are so trivial that they don't seem worth the effort, and the things that cause me problems are so complex, because they depend on exactly what features have been activated, that the permutations are endless and I don't know where to start. However, once it is public, if someone is prepared to do a bit of mentoring, I will start to fill the gap. Documentation is a mess. I did start using Sphinx a while ago, so there is a sprinkling of rest-format docstrings, but they have not been kept up-to-date, and in some cases are out of date. There are plenty of other comments in the code, mostly reminders to myself about various issues. I don't know open-source etiquette. Should I spend the time to sort this out before going public, or is it acceptable to leave it as is for now? Go public first. People might look at your repo and say, ugh, this is a mess, I'm not going to help here, but the alternative is them saying, there is no public repo, and therefore no project, ... Any other comments? Frank Millman -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
2014-08-27 8:06 GMT+02:00 Ian Kelly ian.g.ke...@gmail.com: On Tue, Aug 26, 2014 at 2:12 AM, Amirouche Boubekki amirouche.boube...@gmail.com wrote: 2014-08-26 6:02 GMT+02:00 Ian Kelly ian.g.ke...@gmail.com: On Mon, Aug 25, 2014 at 4:52 AM, Amirouche Boubekki amirouche.boube...@gmail.com wrote: - I am a big fan of Final Fantasy games, it seems to be an easy game experience to code Maybe not so easy, if the horrifying number of bugs in the early games of the series are any indication. I started with FF VII, I don't remember any bugs. Ah, well, that's about when they seem to have gotten their act together with QA. The first and sixth games in particular had some rather notorious game-breaking bugs. I think it says something about the appeal of the series that those were two of the most beloved entries despite all the bugs. Those would have been sold today as alpha and beta for good money. Things change. --- «The interwebs breeding lächerlich from the beginnings, and counting...» -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
2014-08-27 8:23 GMT+02:00 Ian Kelly ian.g.ke...@gmail.com: On Tue, Aug 26, 2014 at 11:43 PM, alex23 wuwe...@gmail.com wrote: On 26/08/2014 6:12 PM, Amirouche Boubekki wrote: 2014-08-26 6:02 GMT+02:00 Ian Kelly ian.g.ke...@gmail.com mailto:ian.g.ke...@gmail.com: It would be just as easy or easier in Python, or one could save a lot more effort by just using RPG Maker like every other indie RPG developer seems to do. I don't think there is FLOSS equivalent. There is indeed: http://openrpgmaker.sourceforge.net/ Ugh. There seems to be no public repository, and the only source to be found is from release-versioned tarballs, so there's apparently no collaboration other than some forums for reporting bugs and requesting features. All the work is done by one developer in his spare time, and he is currently on hiatus since April. Meanwhile the most recent release is February, so it's not like somebody could just pick it up and start hacking and expect to merge. That's only open-source under the most literal of definitions. Screenshots look good in terms of features. -- https://mail.python.org/mailman/listinfo/python-list
Re: What is acceptable as 'open-source'? [was Python vs C++]
On Wednesday, August 27, 2014 5:24:40 PM UTC+5:30, Ned Batchelder wrote: On 8/27/14 3:50 AM, Frank Millman wrote: Ian Kelly wrote in message Ugh. There seems to be no public repository, and the only source to be found is from release-versioned tarballs, so there's apparently no collaboration other than some forums for reporting bugs and requesting features. All the work is done by one developer in his spare time, and he is currently on hiatus since April. Meanwhile the most recent release is February, so it's not like somebody could just pick it up and start hacking and expect to merge. That's only open-source under the most literal of definitions. This is quite a timely message for me. I am inching closer to releasing a version of my accounting software, and a lot of the above comments apply to me as well. At present I am the only developer, and my project is not hosted anywhere, so I have to decide how to make it available, and I am open to suggestions. I have had two attempts at running an hg repository locally, and I am afraid that I am not keeping it up to date. I do have a master copy, but I have made so many changes in my clone that a merge will not make any sense, so I will have to start afresh. I think that making it public will be the only way that I can force myself to update it regularly. You don't need a local hg repo, you just need a working tree. I recommend choosing either hg or git, and then using BitBucket or Github, and being done with it. I could stick to hg (or git) but I have recently come across fossil, and it seems ideal for my needs. Has anyone used it? It seems to have everything it needs (a wiki and a ticketing system) for self-hosting, and I have my own domain that I have not activated yet, so maybe I should just use fossil and host it myself. Any comments? Fossil is one of those technologies that is very attractive in and of itself, but is so under-adopted that it will itself be a barrier to collaboration. (Frankly, hg is getting to that category also.) Some plainspeak -- Nice! In modern society we are part users, part masters. It may be 99% user 1% master if one is super-intelligent versatile etc -- renaissance men. For us more ordinary folk it is more like 99.99% vs 0.01% Eg I dont know how to repair the car I drive, build the roads they run on, a frigging clue about the intenals of the utilities (electricity/water...) I consume etc. Heck this is even true of computers -- the SMPS? the Disk? Likewise versioning systems. We need to use them. We dont need to master all the details and possibilities. Git has won the battle -- maybe because of the mystique around the name 'Torvalds', maybe for sound technical reasons. It doesn't matter. If you have better things in your life than becoming a phd in versioning, I'd say flow with the tide and switch to git -- https://mail.python.org/mailman/listinfo/python-list
hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]
On 08/27/2014 10:29 AM, Rustom Mody wrote: Git has won the battle Good thing there's room for more than one technology. I use hg because 1) python-dev uses hg; and 2) I understand the simple hg commands. I find git confusing, and my main uses are commit, pull, update, an occasional merge, and a rare rollback -- not complicated stuff. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]
On 08/27/2014 11:51 AM, Skip Montanaro wrote: Thank God for StackOverflow. :-) +1 QotW -- https://mail.python.org/mailman/listinfo/python-list
Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]
On Wed, Aug 27, 2014 at 1:26 PM, Ethan Furman et...@stoneleaf.us wrote: I use hg because 1) python-dev uses hg; and 2) I understand the simple hg commands. I find git confusing, and my main uses are commit, pull, update, an occasional merge, and a rare rollback -- not complicated stuff. The simple hg commands are generally not all that different (in my limited experience) than the simple git commands, for some definition of simple. Stuff like clone, init, push, pull, commit, the small number of commands you use day in, day out. When you get beyond that simple core, both are confusing to me. I think it all boils down to what you use most often. At work they settled on git awhile ago, so I'm now comfortable with the basics there, though I recently had a rather unpleasant first experience with git rebase. Both hg (almost all of it for me) and git (the stuff I don't regularly use) are like Perl: I need to consult the documentation every step of the way. Thank God for StackOverflow. :-) Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: What is acceptable as 'open-source'? [was Python vs C++]
Am 27.08.14 09:50, schrieb Frank Millman: This is quite a timely message for me. I am inching closer to releasing a version of my accounting software, and a lot of the above comments apply to me as well. At present I am the only developer, and my project is not hosted anywhere, so I have to decide how to make it available, and I am open to suggestions. [...] I could stick to hg (or git) but I have recently come across fossil, and it seems ideal for my needs. Has anyone used it? It seems to have everything it needs (a wiki and a ticketing system) for self-hosting, and I have my own domain that I have not activated yet, so maybe I should just use fossil and host it myself. Any comments? Fossil is indeed an impressive piece. It comes from Richard Hipp, the guy behind SQLite, and it's currently in use to manage the Tcl/Tk sources. If you want to do the hosting yourself, it can be a good choice. I myself decided not to use it, but instead use git with github. The reasons: - github offers much more than plain git; you can host a website in the repo, included is a (rudimentary) templating engine, which allows to write your docs in simple markdown [*] - the github frontpage makes it easier to download a tarball of the project. In the fossil website it's quite hard to find - github gives the server storage for free to open source projects - there is a social network - anybody who wants to contribute, can send you pull requests via github - For large projects, git is much faster than fossil to update the repo. The good news: you can migrate from fossil to git; e.g. the tcl/tk repos are mirrored to github. For fossil, there is also public storage space e.g. on chiselapp.com as an alternative Christian [*] in case you are curious, this is the website of my repo: http://auriocus.github.io/VecTcl/ The content is all done in markdown, including math and syntax highlighting, and the template was adopted from one of the designs offered from github -- https://mail.python.org/mailman/listinfo/python-list
Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]]
On Thu, Aug 28, 2014 at 4:51 AM, Skip Montanaro s...@pobox.com wrote: The simple hg commands are generally not all that different (in my limited experience) than the simple git commands, for some definition of simple. Stuff like clone, init, push, pull, commit, the small number of commands you use day in, day out. When you get beyond that simple core, both are confusing to me. I think it all boils down to what you use most often. At work they settled on git awhile ago, so I'm now comfortable with the basics there, though I recently had a rather unpleasant first experience with git rebase. Both hg (almost all of it for me) and git (the stuff I don't regularly use) are like Perl: I need to consult the documentation every step of the way. Thank God for StackOverflow. :-) +1. And most importantly: Use source control even though you don't understand all the ins and outs of the one you're using, because you can always get help when something goes wrong. I got my family (mostly non-technical people, or technical people from decades ago - my dad's been in computing since before I was born, but he doesn't know most of the modern tools) to use a git repo instead of a shared directory, basically by giving them very clear and simple instructions: git pull --rebase to see other people's changes, git add when you create a new file, git commit -a to record your changes, git push to send the changes to the central server. (Yes, I know git doesn't need a central server. It's still much simpler to describe it all that way.) If anything goes wrong, they call me for help. They don't need to understand about the myriad ways to call on git log, they don't need to worry about bisecting, they don't even need to branch/merge... and git happily runs for them, every single day. The simple hg/git commands will get you through a pretty huge amount of coding. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
2014-08-26 6:02 GMT+02:00 Ian Kelly ian.g.ke...@gmail.com: On Mon, Aug 25, 2014 at 4:52 AM, Amirouche Boubekki amirouche.boube...@gmail.com wrote: - I am a big fan of Final Fantasy games, it seems to be an easy game experience to code Maybe not so easy, if the horrifying number of bugs in the early games of the series are any indication. I started with FF VII, I don't remember any bugs. I'm not sure what makes this a C++ project in any case. True. It would be just as easy or easier in Python, or one could save a lot more effort by just using RPG Maker like every other indie RPG developer seems to do. I don't think there is FLOSS equivalent. Anyway, I have other ideas: - An after effect equivalent - This might be the same thing as the above, a live processing of vidéos. I tried using python bindings of gstreamer six months ago, I failed. Part of the failure is that g-software suite doesn't care much about this usecase. - port torus trooper to C++ ( http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html) - Contribute to cling, cern's C++ interpreter based on llvm http://root.cern.ch/drupal/content/cling. I think PyPy people are interested to use it too. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 26/08/2014 6:12 PM, Amirouche Boubekki wrote: 2014-08-26 6:02 GMT+02:00 Ian Kelly ian.g.ke...@gmail.com mailto:ian.g.ke...@gmail.com: It would be just as easy or easier in Python, or one could save a lot more effort by just using RPG Maker like every other indie RPG developer seems to do. I don't think there is FLOSS equivalent. There is indeed: http://openrpgmaker.sourceforge.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 24/08/2014 7:14 PM, Robert Kern wrote: On 2014-08-22 01:26, Chris Angelico wrote: Every time Cython gets discussed, I get a renewed desire to learn it. Trouble is, I don't have any project that calls for it - there's nothing I'm desperately wanting to do that involves both Python and C/C++. Anyone got any suggestions? :) Class-based, Python 3-compatible bindings for libtcod? http://doryen.eptalys.net/libtcod/ I would definitely fund a Kickstarter for this. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Héllo, 2014-08-21 14:54 GMT+02:00 David Palao dpalao.pyt...@gmail.com: Why to use C++ instead of python? It is not ranting against C++. I was/am looking for small-medium projects to exercise my C++ skills. But I'm interested in a genuine C++ project: some task where C++ is really THE language (and where python is actually a bad ab initio choice). - You can try to write a game or a game engine. - online book about writing game illustrated in C++ http://gameprogrammingpatterns.com/ - voxels are all the rage, but the only framework I know that is not minecraft-like is still closed source http://www.voxelquest.com/ - I am a big fan of Final Fantasy games, it seems to be an easy game experience to code - Contribute to valve opengl debugger, becarful awesomeness ahead, https://github.com/ValveSoftware/vogl - Contribute to one of the C++ graphical framework: Ogre, blender, Qt - Not rigorously a game: contribute to blender: it's written in C, C++ and Python. - make new graphical devices easy to use from Python, I'm thinking about occulus rift and http://hello.vxbx.net/ - Contribute to Inkscape - Contribute to scikit.learn I think they use Cython and C++ to improve performance. Regarding games I like this book: http://fabiensanglard.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
2014-08-25 12:52 GMT+02:00 Amirouche Boubekki amirouche.boube...@gmail.com : Héllo, 2014-08-21 14:54 GMT+02:00 David Palao dpalao.pyt...@gmail.com: Why to use C++ instead of python? It is not ranting against C++. I was/am looking for small-medium projects to exercise my C++ skills. But I'm interested in a genuine C++ project: some task where C++ is really THE language (and where python is actually a bad ab initio choice). - You can try to write a game or a game engine. - online book about writing game illustrated in C++ http://gameprogrammingpatterns.com/ - voxels are all the rage, but the only framework I know that is not minecraft-like is still closed source http://www.voxelquest.com/ - I am a big fan of Final Fantasy games, it seems to be an easy game experience to code - Contribute to valve opengl debugger, becarful awesomeness ahead, https://github.com/ValveSoftware/vogl - Contribute to one of the C++ graphical framework: Ogre, blender, Qt - Not rigorously a game: contribute to blender: it's written in C, C++ and Python. - make new graphical devices easy to use from Python, I'm thinking about occulus rift and http://hello.vxbx.net/ - Contribute to Inkscape - Contribute to scikit.learn I think they use Cython and C++ to improve performance. Regarding games I like this book: http://fabiensanglard.net/ Back in the days of my C++ I liked http://yosefk.com/c++fqa/ Also they are a few graph database written in C++ that might need some love: - https://www.arangodb.org/ - https://github.com/google/cayley Peace and prosperity -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 8/23/2014 9:00 AM, Chris Angelico wrote: On Sat, Aug 23, 2014 at 10:38 PM, Rustom Mody rustompm...@gmail.com wrote: Here is an example (not identical but analogous to) where markup+compile is distinctly weaker than wysiwyg: You can use lilypond to type music and the use a midi player to play it But lilypond does not allow playing and seeing-in-realtime WYSIWYG editors allow that -- can make a huge difference to beginners who find music hard to read. I don't buy that it's weaker. In fact, I'd say this proves that markup is distinctly better - just a little harder to do Hello, world in. At best, the simple GUI makes it easier to do something straight-forward, and then basically lets you drop to the more complicated form. At worst, it makes it easier to do the very simple, and nearly impossible to do the more complicated. The worst part of using a WYSIWIG program is the frustration of correcting a bewildering problem when some kind of autoformatting magic goes wrong. One odd example is when using Word to compose template documents meant for merging with external data. The markup+compile phase takes on a whole new, horrible meaning. My ears are turning red just imagining the next time I have to do it. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Mon, Aug 25, 2014 at 4:52 AM, Amirouche Boubekki amirouche.boube...@gmail.com wrote: - I am a big fan of Final Fantasy games, it seems to be an easy game experience to code Maybe not so easy, if the horrifying number of bugs in the early games of the series are any indication. I'm not sure what makes this a C++ project in any case. It would be just as easy or easier in Python, or one could save a lot more effort by just using RPG Maker like every other indie RPG developer seems to do. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 2014-08-22 01:26, Chris Angelico wrote: On Fri, Aug 22, 2014 at 4:05 AM, Joseph Martinot-Lagarde joseph.martinot-laga...@m4x.org wrote: For information, Cython works with C++ now: http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html. Now isn't that cool! Every time Cython gets discussed, I get a renewed desire to learn it. Trouble is, I don't have any project that calls for it - there's nothing I'm desperately wanting to do that involves both Python and C/C++. Anyone got any suggestions? :) Class-based, Python 3-compatible bindings for libtcod? http://doryen.eptalys.net/libtcod/ -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Le 23/08/2014 16:21, Chris Angelico a écrit : On Sun, Aug 24, 2014 at 12:02 AM, Ian Kelly ian.g.ke...@gmail.com wrote: I don't know how fast lilypond is, but perhaps one could write an editor that wraps lilypond and invokes it in realtime to show the output in an adjacent panel, perhaps with a brief delay when the user stops typing. You theoretically could, but it'd be a bit awkward in places. It's not hard for a small textual change to result in a large visual change (eg if you use relative notes and add/remove an octave shift - it'll shift every subsequent note in the staff, which might mean more/less ledger lines needed, which will affect how much vertical space the staff needs, which will affect pagination...), so it'd often make for rather nasty flicker. Better to keep it explicit. ChrisA Frescobaldi (http://www.frescobaldi.org/) works exactly like this. It's like a latex IDE but for lilypond. It's quite powerfull and multiplatform. I use it exclusively now, it's way better that the bash script I used before that more or less rebuild the files when changed. This way you get the power of plain text and you have an almost instantaneous snapshot of the end result. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Sat, Aug 23, 2014 at 3:56 PM, dieter die...@handshake.de wrote: Chris Angelico ros...@gmail.com writes: Frankly, I wouldn't write OO in anything, because I think the entire concept of a WYSIWYG editor is flawed. That would limit (so called) office applications to experts only. But the success of these applications relies on the fact, that even a complete novice can immediately use them. For non-experts WYSIWYG editors are important. People say that. But WYSIWYG editors are the primary cause of frustrated yelling from the far end of the house, in my experience. I think they're an attractive nuisance. They're complicated to get right (pure WYSIWYG is useless, so you have to balance the visual benefit of being close to the result against the utility of seeing some of the non-printing information), and non-modular. With a text editor + compiler concept (whether the compiler's language is as big and complex as LaTeX or as simple as ReST), you can change editors without breaking anything. You don't like Libre Office Writer? Tough, there's no real alternative if you want to work on LO files. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Chris Angelico ros...@gmail.com: I'm just saying that callbacks are inherently restrictive in a language without first-class functions. You don't have to go that far to have great callback support. C# (and Delphi) show a great model that I wish C++ had adopted from the beginning. C++ could have declared that a function pointer contains the function pointer plus the (optional) this pointer. That would have dealt with the whole (important) issue. So I'm not sure why you have further issue with C++; C's way of doing callbacks works fine in C++, and there's not going to be anything better. Well, C++11 brings in the lambda (URL: http://www.cprogramming.com/c++11/c++11-lambda-closures.html): One of the biggest beneficiaries of lambda functions are, no doubt, power users of the standard template library algorithms package. Previously, using algorithms like for_each was an exercise in contortions. Using void pointers in C++ is like sacrificing to the idols. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Chris Angelico ros...@gmail.com writes: On Sat, Aug 23, 2014 at 3:56 PM, dieter die...@handshake.de wrote: Chris Angelico ros...@gmail.com writes: Frankly, I wouldn't write OO in anything, because I think the entire concept of a WYSIWYG editor is flawed. That would limit (so called) office applications to experts only. But the success of these applications relies on the fact, that even a complete novice can immediately use them. For non-experts WYSIWYG editors are important. People say that. But WYSIWYG editors are the primary cause of frustrated yelling from the far end of the house, in my experience. I think they're an attractive nuisance. They're complicated to get right (pure WYSIWYG is useless, so you have to balance the visual benefit of being close to the result against the utility of seeing some of the non-printing information), and non-modular. With a text editor + compiler concept (whether the compiler's language is as big and complex as LaTeX or as simple as ReST), you can change editors without breaking anything. You don't like Libre Office Writer? Tough, there's no real alternative if you want to work on LO files. The other problem is that because people are so used to using Word for all text preparation we end up with Word files being used to carry content for which plain text is just fine and would be preferable. The conflation of text editing / word processing / desk top publishing is problematic on a lot of levels. I'm unconvinced is that e.g. LaTeX is inherently more expert that Word for simple document preparation. It's mostly a question of familiarity. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Sat, Aug 23, 2014 at 5:36 PM, Paul Rudin paul.nos...@rudin.co.uk wrote: I'm unconvinced is that e.g. LaTeX is inherently more expert that Word for simple document preparation. It's mostly a question of familiarity. I think LaTeX probably is, in the same way that PhotoShop or Gimp is more expert than a simple paint program, but something like ReST should be easy for anyone to work with... and it'd require less familiarity than Word does before you get to call yourself an expert. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Saturday, August 23, 2014 3:19:37 AM UTC+5:30, Chris Angelico wrote: On Sat, Aug 23, 2014 at 7:38 AM, Michael Torrie wrote: On 08/22/2014 02:06 PM, Marko Rauhamaa wrote: I tend to think the opposite: C++ barely has a niche left. I definitely wouldn't want to use C++ very far from its (very narrow) sweet spot. I agree that it's niche is narrowing. But it's still pretty wide and widely used. Many adobe products are C++, for example. OpenOffice and LibreOffice is C++. You could argue that's because they are old projects and were started in C++. But honestly if you were reimplementing OpenOffice today what would you choose? Python would be appropriate for certain aspects of OO, such as parts of the UI, macros, filters, etc. ... Frankly, I wouldn't write OO in anything, because I think the entire concept of a WYSIWYG editor is flawed. Much better to use markup and compile it. But if I were to write something like that, probably what I'd do would be to write a GUI widget in whatever lowish-level language is appropriate (probably C, with most GUI toolkits), and then use a high level language (probably Python or Pike) to build the application. I'm not familiar with all of OO/LO's components, but I believe that model will probably work for all of them (the document editor, obviously; the presentation editor might be done a bit differently, but it'd still work this way; the spreadsheet quite possibly doesn't even need a custom widget; etc). Here is an example (not identical but analogous to) where markup+compile is distinctly weaker than wysiwyg: You can use lilypond to type music and the use a midi player to play it But lilypond does not allow playing and seeing-in-realtime WYSIWYG editors allow that -- can make a huge difference to beginners who find music hard to read. Here's an example I typed out in the wysiwig editor nted https://vimeo.com/16894001 ¹ Many more examples like this on the musescore site eg http://musescore.com/user/19710/scores/261621 I believe that in a like way an app like Word that has a full (Turing complete) language -- VBA -- is more powerful than an offline tool like lilypond ¹ No I dont enjoy clickety-click when a typewriter would work better. I know a musician friend who has worked out the best combo: type in with a cheap midi connected keyboard, then use Sibelius. I believe its only a question of time before musescore like wysiwyg editors will be able to do that -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Sat, Aug 23, 2014 at 10:38 PM, Rustom Mody rustompm...@gmail.com wrote: Here is an example (not identical but analogous to) where markup+compile is distinctly weaker than wysiwyg: You can use lilypond to type music and the use a midi player to play it But lilypond does not allow playing and seeing-in-realtime WYSIWYG editors allow that -- can make a huge difference to beginners who find music hard to read. I don't buy that it's weaker. In fact, I'd say this proves that markup is distinctly better - just a little harder to do Hello, world in. At best, the simple GUI makes it easier to do something straight-forward, and then basically lets you drop to the more complicated form. At worst, it makes it easier to do the very simple, and nearly impossible to do the more complicated. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Sat, Aug 23, 2014 at 6:38 AM, Rustom Mody rustompm...@gmail.com wrote: Here is an example (not identical but analogous to) where markup+compile is distinctly weaker than wysiwyg: You can use lilypond to type music and the use a midi player to play it But lilypond does not allow playing and seeing-in-realtime WYSIWYG editors allow that -- can make a huge difference to beginners who find music hard to read. I don't know how fast lilypond is, but perhaps one could write an editor that wraps lilypond and invokes it in realtime to show the output in an adjacent panel, perhaps with a brief delay when the user stops typing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Sun, Aug 24, 2014 at 12:02 AM, Ian Kelly ian.g.ke...@gmail.com wrote: I don't know how fast lilypond is, but perhaps one could write an editor that wraps lilypond and invokes it in realtime to show the output in an adjacent panel, perhaps with a brief delay when the user stops typing. You theoretically could, but it'd be a bit awkward in places. It's not hard for a small textual change to result in a large visual change (eg if you use relative notes and add/remove an octave shift - it'll shift every subsequent note in the staff, which might mean more/less ledger lines needed, which will affect how much vertical space the staff needs, which will affect pagination...), so it'd often make for rather nasty flicker. Better to keep it explicit. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Saturday, August 23, 2014 7:32:12 PM UTC+5:30, Ian wrote: On Sat, Aug 23, 2014 at 6:38 AM, Rustom Mody rusto...@gmail.com wrote: Here is an example (not identical but analogous to) where markup+compile is distinctly weaker than wysiwyg: You can use lilypond to type music and the use a midi player to play it But lilypond does not allow playing and seeing-in-realtime WYSIWYG editors allow that -- can make a huge difference to beginners who find music hard to read. I don't know how fast lilypond is, but perhaps one could write an editor that wraps lilypond and invokes it in realtime to show the output in an adjacent panel, perhaps with a brief delay when the user stops typing. Yes. Wordperfect was one of the best wysiwyg editors Ive used. One could use it in normal (1-screen) mode Or one could split the screen and see the formattings in the lower window along withe the formatted in the upper. Which is to say I believe weve not the heard the last of finding the best mix between WYSIWYG and coded-text+compile This the same as what you are saying because if one writes the editor to wrap lilypond and show in another window the next step is to allow editing in either windows and have the app keep them in sync -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 22/08/2014 18:16, Marko Rauhamaa wrote: SCons gives you the power of Python. Don't use that power except in utmost need. Ah, you've seen our build system at work! Andy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
mm0fmf n...@mailinator.com: On 22/08/2014 18:16, Marko Rauhamaa wrote: SCons gives you the power of Python. Don't use that power except in utmost need. Ah, you've seen our build system at work! Where I've used SCons, I've striven to make the SConscript files obvious to a casual visitor, who might not even know Python. Adding one more file in the right spot should be possible just from the looks of the SConscript file. A SConscript file should *not* involve programming, even if it means some redundancy. Don't create libraries. Don't create your own rules. Keep it simple, keep it plain. A colleague had to deal with a different SCons setup that had reached self-awareness. It knew what needed to be built without specific instructions before you, the developer, knew it yourself. The developers no longer had any idea how it worked nor did they dream of touching the code. Not a good place to be. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 8/23/2014 8:38 AM, Rustom Mody wrote: WYSIWYG editors allow that -- can make a huge difference to beginners who find music hard to read. Here's an example I typed out in the wysiwig editor nted https://vimeo.com/16894001 ¹ Awww, snap! This video can’t be played with your current setup How informative. At least we try to do better with Python exception messages. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 8/23/2014 10:21 AM, Rustom Mody wrote: Wordperfect was one of the best wysiwyg editors Ive used. One could use it in normal (1-screen) mode Or one could split the screen and see the formattings in the lower window along withe the formatted in the upper. I wrote at least two books with Wordperfect. Seeing the formatting code was essential to get the detail correct. Word, and even OO and LO are downgrades in this respect. At least with LO, one can get or enable saving as flat xml and edit at that level. Which is to say I believe weve not the heard the last of finding the best mix between WYSIWYG and coded-text+compile I'd like to have side-by-side windows with LO. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
David Palao dpalao.pyt...@gmail.com writes: Why to use C++ instead of python? Likely, you would not use Python to implement most parts of an operating system (where, for efficiency reasons, some parts are even implemented in an assembler language). I can imagine that the GNU compiler developers, too, had good reasons to implement them in C rather than a scripting language. It makes a huge difference whether you wait one or several hours before a large system is built. firefox, too, seems to be implemented in C/C++. There, too, I see good reasons: * it is nice when your pages are rendered quickly * firefox depends on lots of external libraries, all of them with C/C++ interfaces; while is is possible to create Python bindings for them, this is quite some work * as it is, firefox is a huge memory eater; one might fear that things would be worse if implemented in a higher level language (with everything on the heap). Though, the fear might not be justified. All these examples are really large projects. I like Python a lot for smaller projects. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Fri, Aug 22, 2014 at 4:12 PM, dieter die...@handshake.de wrote: Likely, you would not use Python to implement most parts of an operating system (where, for efficiency reasons, some parts are even implemented in an assembler language). I can imagine that the GNU compiler developers, too, had good reasons to implement them in C rather than a scripting language. It makes a huge difference whether you wait one or several hours before a large system is built. firefox, too, seems to be implemented in C/C++. There, too, I see good reasons: * it is nice when your pages are rendered quickly * firefox depends on lots of external libraries, all of them with C/C++ interfaces; while is is possible to create Python bindings for them, this is quite some work * as it is, firefox is a huge memory eater; one might fear that things would be worse if implemented in a higher level language (with everything on the heap). Though, the fear might not be justified. All these examples are really large projects. I like Python a lot for smaller projects. Yep. But it's not so much large vs small projects; these are all situations where it's entirely plausible to saturate a CPU core for a while, so the performance penalty of a high level language will actually matter. (That said, though: Firefox has a lot of non-performance-critical code, which AIUI is implemented in a higher level language than C. And a long 'make' run probably involves some shell scripting and such, not pure C code. Even high performance projects have their less-critical parts.) Similarly, I'd be pretty worried if someone rewrote X11 in Python. But if your program's going to spend most of its time waiting (for the user, for the network, for the real-time clock), halving its CPU usage won't materially affect anything, and halving development time will make a huge difference. That's when Python is an excellent choice. At my last job, we had some parts written in Pike, some written in PHP (not just the web site), and one back-end engine in C++. Toward the end, I wanted to redo the C++ engine in Python or Pike, because I didn't think the performance hit would be at all visible, and it would have been much easier to work on. (I'd also been progressively taking over jobs that PHP code had been doing and giving them to Pike processes instead, with a not-so-secret goal of eventually ripping out the PHP engine altogether. But that for other reasons.) As a back-end process, its performance would be hard for the end user to see directly, so the cost of a high level language would simply have been that the server could cope with fewer requests per hour before we need to requisition more hardware. Alas, there wasn't development time available for the translation (we were far too busy doing things about which I said YAGNI and the boss said Do it anyway), but I firmly believe that we wouldn't have been suffering from the performance hit. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
dieter schrieb am 22.08.2014 um 08:12: David Palao writes: Why to use C++ instead of python? Likely, you would not use Python to implement most parts of an operating system (where, for efficiency reasons, some parts are even implemented in an assembler language). I can imagine that the GNU compiler developers, too, had good reasons to implement them in C rather than a scripting language. It makes a huge difference whether you wait one or several hours before a large system is built. firefox, too, seems to be implemented in C/C++. There, too, I see good reasons: * it is nice when your pages are rendered quickly * firefox depends on lots of external libraries, all of them with C/C++ interfaces; while is is possible to create Python bindings for them, this is quite some work * as it is, firefox is a huge memory eater; one might fear that things would be worse if implemented in a higher level language (with everything on the heap). Though, the fear might not be justified. All these examples are really large projects. I like Python a lot for smaller projects. While I agree that there are very valid reasons to write C/C++ code (and operating systems clearly fall into that category), most of the above might turn out to be fallacies. With a more high-level language, it is easier to get a system running and then focus on optimisation than in a low-level language that requires a lot of concentrated work just to get things done at all. Especially in the long run, where the maintenance burden of low-level code starts getting so much in the way that it becomes harder and harder to keep improving the system and adding new features. If, instead, you start with a high-level language, your first implementation might not be as fast as your first C++ implementation could have been, but it'll be almost certainly available much earlier, so that you can then give it real world testing and performance evaluation. That gives you a head start for optimisation and improvements, which then leads to a faster system again. Thus, it's not unlikely that you already get an even faster and better system (in terms of actual user experience) in the same timeframe that you would otherwise have spent on getting even a first working version of your system in a low-level language. And the optimisation that you apply to your system may still include rewriting parts of it in C++, but then really only those parts where real world evaluation proved that it's worth the effort and maintenance overhead. I've given a talk about this topic at PyCon-DE 2012. It's in German, but it contains a lot of figures that should be understandable even if you don't understand that language. http://consulting.behnel.de/PyConDE/2012/ohnecpp.html Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Am 21.08.14 14:54, schrieb David Palao: I consider myself a python programmer, although C++ was one of the first languages I learned (not really deeply and long time ago). Now I decided to retake C++, to broaden my view of the business. However, as I progress in learning C++, I cannot take out of my head one question Why to use C++ instead of python? You are asking in the wrong group; ask this in comp.lang.c++ Here most of the programmers know Python well and maybe some C++ It is not ranting against C++. I was/am looking for small-medium projects to exercise my C++ skills. But I'm interested in a genuine C++ project: some task where C++ is really THE language (and where python is actually a bad ab initio choice). The truth is, that both languages have a fairly large overlap. C++ spans a very wide gap, from tight low-level loops and direct memory access close to the metal up to composing a GUI application from ready-made building blocks. There is a variety of programming paradigmata, like functional (so-so), object oriented (quite good), generic (very good), imperative (shiny = the C subset). Graphically C++: metal |--| Python: metal || If your application lives within the overlap region, and a lot of them do, the choice is a matter of taste. I'm not even convinced that the development time is significantly lower in Python within this overlap. It becomes different at both ends: The more you go to the higher level, the more will Python outperform C++ in terms of development costs, but conversely C++ will win if you go closer to the metal. Then, as a Python programmer, you will find yourself rewriting parts of the application in Cython, trying PyPy, numpy, finally embedding C... A few arguments outside of what I can do with it have already been given: * For deployment, it is nice to compile and link a self-contained small binary. Try that with matplotlib - pyinstaller gets me a 100MB executable containing OS libraries, while the linker in C++ is able to only link what is needed. * Access to the hardware: C structs, raw pointers, unboxed datatypes are needed in a painless and efficient way if you want to write, say, a middle-level device driver * performance is not only speed, but also memory usage. In most cases a C++ program will consume less memory * static type checking can find bugs at compile-time. C++ is easier to compile (though on of the harder languages for compiler implementers), and therefore many tools exist for static analysis. The usual argument in favour of C++ (when comparing to python) is performance. But I'm convinced that, in general, the right approach is python-profiling-(extension/numpy/Cython/...). Well, that's Ousterhouts dichotomy. Christian Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Fri, Aug 22, 2014 at 6:05 PM, Christian Gollwitzer aurio...@gmx.de wrote: I'm not even convinced that the development time is significantly lower in Python within this overlap. It usually will be, though not always. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Chris Angelico ros...@gmail.com: On Fri, Aug 22, 2014 at 6:05 PM, Christian Gollwitzer aurio...@gmx.de wrote: I'm not even convinced that the development time is significantly lower in Python within this overlap. It usually will be, though not always. Even more to the point, it is far easier to program correctly in Python than C++. The higher-level concepts let you concentrate on the high-level problem at hand instead of the low-level chores where you are bound to make careless mistakes or take dangerous shortcuts. So my advise is, use as high-level programming language as you can. If you can't, deal with it, but often you can break your system into parts where only a small corner needs to be implemented at the low level. Remember, too, that there is a whole sliding scale of programming languages: assembly C C++ Go Java/C# Python Scheme Bash In my current work, the choice is between C, Python and Bash. Some non-STL C++ in the mix. In my previous job, it was Java, Python and Bash, with some JNI in the mix. I think Python's abstraction level is excellent for most needs. C++ is squeezed from all sides. Its downfall is that it is trying to cover everything instead of just ceding the high-level turf to other languages. Thus, it is too elaborate for the nimble stuff, and you will often simply use C where you need nimble. C is readily supported by all extension APIs. Its calling conventions are stable and well-understood. Its runtime requirements are trivial. Plus, you don't have to be a Medieval Scholar to program in it. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 8/22/2014 5:29 AM, Marko Rauhamaa wrote: C is readily supported by all extension APIs. Its calling conventions are stable and well-understood. Its runtime requirements are trivial. Plus, you don't have to be a Medieval Scholar to program in it. C itself is very simple (albeit not simple to use). But I contend you do need to be a Medieval Scholar to compile and link it. My mind boggles watching a ./configure vomit ASCII all over my screen. I have to avert my eyes, make a wish, and make install. ;) -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Fri, Aug 22, 2014 at 7:51 AM, Neil D. Cerutti ne...@norwich.edu wrote: But I contend you do need to be a Medieval Scholar to compile and link it. That's only because whoever wrote your Makefile wasn't skilled in the art of make recipes. :-) Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Fri, Aug 22, 2014 at 10:51 PM, Neil D. Cerutti ne...@norwich.edu wrote: C itself is very simple (albeit not simple to use). But I contend you do need to be a Medieval Scholar to compile and link it. My mind boggles watching a ./configure vomit ASCII all over my screen. I have to avert my eyes, make a wish, and make install. ;) Bah, it's more fun to actually read it, and to imagine what manner of system might fail some of those tests :) checking for candle... no checking whether the C compiler works... yes checking for stdlib.h... yes checking for windows.h usability... no checking for windows.h presence... no (these last two on a system that had already been probed and found to be Linux) And of course: checking whether build environment is sane... http://xkcd.com/371/ ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 08/21/2014 06:54 AM, David Palao wrote: Hello, I consider myself a python programmer, although C++ was one of the first languages I learned (not really deeply and long time ago). Now I decided to retake C++, to broaden my view of the business. However, as I progress in learning C++, I cannot take out of my head one question Why to use C++ instead of python? Get yourself a cheap arduino-compatible board ($20 or so) and then start programming it. The Arduino framework is C++. It's kind of fun to program in such a small, compact environment. C++ actually suits it fairly well. What I sometimes do is mock up an arduino project on the PC using python (talking directly to arduino I/O pins using a special firmware that talks over the serial port), and then convert it to C++ to run directly on the arduino. Another project combines arduino with a raspberry pi or like device. C++ code runs on the arduino, and Python runs on the pi to communicate with it and do things like provide a web interface. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Le 22/08/2014 02:26, Chris Angelico a écrit : On Fri, Aug 22, 2014 at 4:05 AM, Joseph Martinot-Lagarde joseph.martinot-laga...@m4x.org wrote: For information, Cython works with C++ now: http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html. Now isn't that cool! Every time Cython gets discussed, I get a renewed desire to learn it. Trouble is, I don't have any project that calls for it - there's nothing I'm desperately wanting to do that involves both Python and C/C++. Anyone got any suggestions? :) ChrisA A python API for OpenSceneGraph ? I wouldn't use cython for this, though... -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Skip Montanaro s...@pobox.com: On Fri, Aug 22, 2014 at 7:51 AM, Neil D. Cerutti ne...@norwich.edu wrote: But I contend you do need to be a Medieval Scholar to compile and link it. That's only because whoever wrote your Makefile wasn't skilled in the art of make recipes. :-) Make shouldn't be involved in any serious work. It was designed for the case where you have a handful of source files in a single directory. Its use has gotten completely out of hand. I sincerely recommend SCons for anything more serious. A word of warning, though: SCons gives you the power of Python. Don't use that power except in utmost need. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Friday, August 22, 2014 8:26:00 AM UTC+8, Chris Angelico wrote: On Fri, Aug 22, 2014 at 4:05 AM, Joseph Martinot-Lagarde joseph.martinot-laga...@m4x.org wrote: For information, Cython works with C++ now: http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html. Now isn't that cool! Every time Cython gets discussed, I get a renewed desire to learn it. Trouble is, I don't have any project that calls for it - there's nothing I'm desperately wanting to do that involves both Python and C/C++. Anyone got any suggestions? :) ChrisA Don't you use C as a portable assembler in Python? PYTHON-C-HW_BOUNDED_ASSEMBLY That is the way to speed up python programs using critical heavy computing functions. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Am 22.08.14 11:29, schrieb Marko Rauhamaa: So my advise is, use as high-level programming language as you can. If you can't, deal with it, but often you can break your system into parts where only a small corner needs to be implemented at the low level. Agreed. This is called Ousterhout's dichotomy. Remember, too, that there is a whole sliding scale of programming languages: assembly C C++ Go Java/C# Python Scheme Bash My point is that this picture is incomplete: it shows the programming languages as *points* on the complexity line, whereas they are rather *intervals*. And these intervals have large overlaps. My picture: as |--| c || c++ |---| java |-| python|| * Assembly is really narrow: tiny loops, compiler output snippets, firmware for really small embedded devices - anything beyond should be written in higher languages. * C has a much broader scope: you can do most of the tiny loops and firmware stuff, unless the device is too small or you are bootstrapping a kernel. But it also scales up until command line tools such as sort and even can do moderately complex programs like the CPython interpreter - even if that would be much easier to write in C++. I guess the only reason for CPython instead of C++Python is the better portability of C. * C++ embraces all of C, and by that definition reaches from the low end up to GUI applications - most modern everyday programs are written in C++ in large parts. At the low end, it looses some device driver stuff, because exceptions, RTTI and such features are incompatible with code running in the kernel of an OS. But it still can make good use of memory (class and struct have the same memory layout). On the high end, you can write programs managing high-level data structures without a single explicit pointer or new and delete in your code. * Java: I don't see that it is much higher level than C++. It has a GC, but that's all, and you can have that in C++, too, if you want. On the other hand, you loose the metaprogramming facilities provided by C++ templates (needs a guru to make a library, but can be handy and easy to use, e.g. everything in Boost). You loose direct memory access, gaining what? no idea. * Python: On the low end almost on par with Java, slower because of dynamic typing, no direct memory access. On the high end manages complex libraries with single few invocations, good support for functional-style programming (generators, list comprehensions), the first in this list with an acceptable REPL in the standard distribution - imagine assembly, C++ or even Java with a REPL Scheme - only played with it some time ago, seems to me like the assembly of functional languages. Compare that to Haskell, which is an elaborate high-level language. I wouldn't claim that it is higher-level than Python. I think Python's abstraction level is excellent for most needs. C++ is squeezed from all sides. Its downfall is that it is trying to cover everything instead of just ceding the high-level turf to other languages. Thus, it is too elaborate for the nimble stuff, and you will often simply use C where you need nimble. Ousterhout's dichotomy. It's a good paradigm in many cases, but sometimes it might be preferable to have everything in a single language. And this is a good domain for C++. C is readily supported by all extension APIs. Its calling conventions are stable and well-understood. Its runtime requirements are trivial. Plus, you don't have to be a Medieval Scholar to program in it. I'm currently implementing a numpy-like library for another language in C. I choosed C for the ABI/portability reason, but I am really missing C++ in many, many places. The code is an awful mess of macros to get simple metaprogramming facilities, i.e. to support different data types and operations. This is a domain where C++ would be the best choice, and only the stupid reason of possible runtime dependency guided the decision to use C. Everything which needs string processing, but still has to run fast, is another good candidate. Compilers are certainly less painful to write in C++ than in C, and could still run with native speed. For sure it is much easier to do a compiler in Python, but this will come with a speed penalty (of the compilation, not the code, as evidenced by PyPy). Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
If you want to add Cython to that (overly simplified) graph, you might get something like this: Christian Gollwitzer schrieb am 22.08.2014 um 21:25: as |--| c || c++ |---| Cython || python|| Meaning, there is a lot you can do in Cython that can keep you from having to write C/C++ code at all. And even if you really have to, it still helps in keeping that down to a couple of well chosen snippets rather than full programs. Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
assembly C C++ Go Java/C# Python Scheme Bash My point is that this picture is incomplete: it shows the programming languages as *points* on the complexity line, I don't see any points. I see words. whereas they are rather *intervals*. And these intervals have large overlaps. Add line segments as wide as you'd like. Ousterhout's dichotomy. It's a good paradigm in many cases, but sometimes it might be preferable to have everything in a single language. And this is a good domain for C++. I tend to think the opposite: C++ barely has a niche left. I definitely wouldn't want to use C++ very far from its (very narrow) sweet spot. I'm currently implementing a numpy-like library for another language in C. I choosed C for the ABI/portability reason, but I am really missing C++ in many, many places. The code is an awful mess of macros to get simple metaprogramming facilities, i.e. to support different data types and operations. This is a domain where C++ would be the best choice, and only the stupid reason of possible runtime dependency guided the decision to use C. C++'s gift to programming was to take static typing to its utmost limits -- to the detriment of usability, learnability and intelligibility. STL and Boost have been turned into totems that supposedly turn a dire necessity into a virtue. C's give to programming is the void pointer. It's the antithesis of C++, but damn does it get you out of every bind -- no fuss, no semantic handwringing. My disillusionment with C++ came from the language's inability to represent callbacks. C can do it (void *), C# can do it (delegates), Java can do it (anonymous inner classes), Python can do it (methods), Scheme can do it (closures). Qt needs callbacks (signals IIRC). It doesn't use C++ to express them. It uses a fricking metacompiler for them. And Stroustrup's thick book didn't even seem to be aware of callbacks as a paradigm and thus didn't show any examples of dealing with them. Too bad Stroustrup wasn't aware of C#'s delegates; C++ should have defined function pointers as delegates. Everything which needs string processing, but still has to run fast, is another good candidate. Compilers are certainly less painful to write in C++ than in C, and could still run with native speed. For sure it is much easier to do a compiler in Python, but this will come with a speed penalty (of the compilation, not the code, as evidenced by PyPy). There is one big advantage C++ has over C: virtual method dispatching. However, I have been able to come up with C idioms that make practical method dispatching relatively painless. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 08/22/2014 02:06 PM, Marko Rauhamaa wrote: I tend to think the opposite: C++ barely has a niche left. I definitely wouldn't want to use C++ very far from its (very narrow) sweet spot. I agree that it's niche is narrowing. But it's still pretty wide and widely used. Many adobe products are C++, for example. OpenOffice and LibreOffice is C++. You could argue that's because they are old projects and were started in C++. But honestly if you were reimplementing OpenOffice today what would you choose? Python would be appropriate for certain aspects of OO, such as parts of the UI, macros, filters, etc. I certainly wouldn't want to use Java (contrary to popular belief OO is not written in Java; it's definitely C++). Go is quite young but promising except that unicode is all UTF-8 byte strings, so string operations are going to be a bit slow. C# never lived up to its promise as the next app development language, even on Windows. So at this moment I'd still do it in C++ I think. Apple chose to use C++ to build clang and llvm in, rather than C. My disillusionment with C++ came from the language's inability to represent callbacks. C can do it (void *), C# can do it (delegates), Java can do it (anonymous inner classes), Python can do it (methods), Scheme can do it (closures). C++ can do it quite well, actually. Maybe not quite as nicely as Python. But boost and libsigc++ both offer nice, type-safe ways to implement signals and slots. You can pass references to a callback around in an easy, safe way. Qt needs callbacks (signals IIRC). It doesn't use C++ to express them. It uses a fricking metacompiler for them. This is only partially true. The actual, original, .cpp files with Qt macros in them compile directly on the C++ compiler. moc runs on the .h file to generate some supporting code to help with event dispatching. There's no such thing as Qt C++. It's all standard C++, with macros to help when defining things such as signals. Macros were chosen instead of templates because at the time, not all C++ compilers supported templates. Now if it was done all over again, they'd do something like libsigc++, or boost. And Stroustrup's thick book didn't even seem to be aware of callbacks as a paradigm and thus didn't show any examples of dealing with them. Too bad Stroustrup wasn't aware of C#'s delegates; C++ should have defined function pointers as delegates. Maybe the language doesn't need to implement them as keywords because it's already possible to do safely with templates. libsigc++ is a great implementation that works really well (and it's quite fast at dispatching events). libsigc++ has an advantage over Qt in that the signals are actual type-safe template objects. Qt's signals are actually strings under the hood, and I've had weird name clash issues in the past when I didn't realize that. Can't remember the circumstances or the details now. Basically something that should have been caught at compile time became a runtime error. Doing event-driven programming with Gtkmm and libsigc++ is actually pretty darn nice and is right at home in C++. There is one big advantage C++ has over C: virtual method dispatching. However, I have been able to come up with C idioms that make practical method dispatching relatively painless. Seems like Vala might fit this niche pretty well. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Sat, Aug 23, 2014 at 7:38 AM, Michael Torrie torr...@gmail.com wrote: On 08/22/2014 02:06 PM, Marko Rauhamaa wrote: I tend to think the opposite: C++ barely has a niche left. I definitely wouldn't want to use C++ very far from its (very narrow) sweet spot. I agree that it's niche is narrowing. But it's still pretty wide and widely used. Many adobe products are C++, for example. OpenOffice and LibreOffice is C++. You could argue that's because they are old projects and were started in C++. But honestly if you were reimplementing OpenOffice today what would you choose? Python would be appropriate for certain aspects of OO, such as parts of the UI, macros, filters, etc. ... Frankly, I wouldn't write OO in anything, because I think the entire concept of a WYSIWYG editor is flawed. Much better to use markup and compile it. But if I were to write something like that, probably what I'd do would be to write a GUI widget in whatever lowish-level language is appropriate (probably C, with most GUI toolkits), and then use a high level language (probably Python or Pike) to build the application. I'm not familiar with all of OO/LO's components, but I believe that model will probably work for all of them (the document editor, obviously; the presentation editor might be done a bit differently, but it'd still work this way; the spreadsheet quite possibly doesn't even need a custom widget; etc). My disillusionment with C++ came from the language's inability to represent callbacks. C can do it (void *), C# can do it (delegates), Java can do it (anonymous inner classes), Python can do it (methods), Scheme can do it (closures). C++ can do it quite well, actually. Maybe not quite as nicely as Python. But boost and libsigc++ both offer nice, type-safe ways to implement signals and slots. You can pass references to a callback around in an easy, safe way. My main issue with callbacks in either C or C++ is that functions aren't first-class objects. You can pass function pointers around (and you don't need (void *) to do it, you can use typed function pointers just fine), but you can't actually construct a function at run-time. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 08/22/2014 03:49 PM, Chris Angelico wrote: My main issue with callbacks in either C or C++ is that functions aren't first-class objects. You can pass function pointers around (and you don't need (void *) to do it, you can use typed function pointers just fine), but you can't actually construct a function at run-time. I'm not sure I fully understand your meaning. You seem to prefer dynamic languages, which is great because this is the Python list after all. I'm not sure I know of any statically compiled language that lets one construct a function at run-time. I know Boost supports lambda functions but I'm not sure this is quite what you are referring to either. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Sat, Aug 23, 2014 at 7:56 AM, Michael Torrie torr...@gmail.com wrote: On 08/22/2014 03:49 PM, Chris Angelico wrote: My main issue with callbacks in either C or C++ is that functions aren't first-class objects. You can pass function pointers around (and you don't need (void *) to do it, you can use typed function pointers just fine), but you can't actually construct a function at run-time. I'm not sure I fully understand your meaning. You seem to prefer dynamic languages, which is great because this is the Python list after all. I'm not sure I know of any statically compiled language that lets one construct a function at run-time. I know Boost supports lambda functions but I'm not sure this is quite what you are referring to either. Right, I'm just saying that callbacks are inherently restrictive in a language without first-class functions. So I'm not sure why you have further issue with C++; C's way of doing callbacks works fine in C++, and there's not going to be anything better. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Christian Gollwitzer aurio...@gmx.de writes: ... * Java: I don't see that it is much higher level than C++. It has a GC, but that's all, and you can have that in C++, too, if you want. On the other hand, you loose the metaprogramming facilities provided by C++ templates (needs a guru to make a library, but can be handy and easy to use, e.g. everything in Boost). You loose direct memory access, gaining what? no idea. Automatic memory compaction -- which can be quite helpfull with long running applications (avoiding memory fragmentation). -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Chris Angelico ros...@gmail.com writes: Frankly, I wouldn't write OO in anything, because I think the entire concept of a WYSIWYG editor is flawed. That would limit (so called) office applications to experts only. But the success of these applications relies on the fact, that even a complete novice can immediately use them. For non-experts WYSIWYG editors are important. -- https://mail.python.org/mailman/listinfo/python-list
Python vs C++
Hello, I consider myself a python programmer, although C++ was one of the first languages I learned (not really deeply and long time ago). Now I decided to retake C++, to broaden my view of the business. However, as I progress in learning C++, I cannot take out of my head one question Why to use C++ instead of python? It is not ranting against C++. I was/am looking for small-medium projects to exercise my C++ skills. But I'm interested in a genuine C++ project: some task where C++ is really THE language (and where python is actually a bad ab initio choice). The usual argument in favour of C++ (when comparing to python) is performance. But I'm convinced that, in general, the right approach is python-profiling-(extension/numpy/Cython/...). At least for a python programmer. I might be wrong, though. This is, perhaps, a bit off-topic, but I really want to know the thoughts of experienced python programmers on it. Thanks in advance, David -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 08/21/14 15:54, David Palao wrote: But I'm interested in a genuine C++ project: some task where C++ is really THE language (and where python is actually a bad ab initio choice) For my day job, I chose Qt on C++ for a classic desktop app that needs to be deployed on Windows (among other platforms) with an installation package that is as small as possible. All I need to do deployment-wise is to create an NSIS script putting a couple of DLL's and my executable in a folder in %ProgramFiles% and a shortcutin start menu. The full package is 5 megs and the update archive is pushing half a megabyte. I was also back to C++ after a number of years of exclusive web dev with Python and Javascript. C++11 is just *sweet*, I'd never imagined I'd enjoy doing non-computer-sciencey work with C++. good luck, burak -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Thu, Aug 21, 2014 at 10:54 PM, David Palao dpalao.pyt...@gmail.com wrote: Why to use C++ instead of python? This is, perhaps, a bit off-topic, but I really want to know the thoughts of experienced python programmers on it. No, it's a fair question. Why are we all here? The fact is, there's not a huge amount of reason left. If you're linking against a C++ API, you may find it easiest to do the whole program in C++, rather than use something like Cython (which, as far as I'm aware, is C-only) or write a two-part project. And obviously if you have an existing C++ codebase, then porting it has costs, and maintaining it is probably better. But for the most part, I would strongly recommend starting a project in a high level language like Python unless there's a really compelling reason to do otherwise. C++ has, of late, been growing a number of features that belong in higher level languages; but if you want those sorts of features, why not just grab Python or Pike or something and save yourself the trouble? One possible advantage is compactness. Once you've compiled a C++ program, you don't have to distribute as much stuff with it as an entire Python interpreter. Also, true compilation obscures your source code a lot better than any attempt at a mangled Python would, so if you're trying to demonstrate to upper management that your code isn't being given away, that might be an advantage. (But frankly, even that isn't all that useful. The only way to truly stop people from using your code is to not give it to them in any form, which these days generally means putting it on a server and providing web browser access. And that works just fine for Python code.) There are reasons for using C, of course. I'm not sure whether your question is about C++ specifically, or also about C. But in my opinion, C is for writing high level languages in, and applications should be written in something else. It's like stack-based programming - sure, it's efficient and all, but it's not something you want to spend all day debugging. (If you look at CPython bytecode disassembly, you'll see that the interpreter's actually stack-based; but we don't have to worry about keeping the stack straight, we just write nice clean Python code.) Interfacing with C-level libraries can be done with an absolute minimum of low-level code (probably with Cython), and the main application logic can still be in Python. Let's suppose you're starting a greenfield project, and either Python or C++ would have been the perfect language, but you chose wrongly. What are the consequences? If you chose C++, you have a much heavier development and maintenance cost, and Python would have been good enough, so you get no significant benefit - basically, you miss out on the ease of coding that Python offers you. If you chose Python, what you now have is a proof-of-concept that you can use to prove the correctness of any rewrites (just get a good test suite going and then use the same tests for both engines), at a relatively low development cost. Considering that the cost of erring on Python's side is lower AND the likelihood of Python being correct is higher, I would say that you can safely bet on Python for a new project, and leave C++ until you have some really good reason for taking it up :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 8/21/2014 8:54 AM, David Palao wrote: Hello, I consider myself a python programmer, although C++ was one of the first languages I learned (not really deeply and long time ago). Hey, that sounds just like me. Now I decided to retake C++, to broaden my view of the business. However, as I progress in learning C++, I cannot take out of my head one question I have gone back and attempted to use C++ again a couple of times, but spoiler it turns out to not be worthwhile in my current position. Why to use C++ instead of python? It is not ranting against C++. I was/am looking for small-medium projects to exercise my C++ skills. But I'm interested in a genuine C++ project: some task where C++ is really THE language (and where python is actually a bad ab initio choice). The usual argument in favour of C++ (when comparing to python) is performance. But I'm convinced that, in general, the right approach is python-profiling-(extension/numpy/Cython/...). At least for a python programmer. I might be wrong, though. Python, for me, is the ultimate translator and aggregator of data. I use it constantly to get data from one place, combine it with some other data over there, fiddle with it, and spit it out in some usable manner. I could certainly use C++ for my projects. I think the standard containers, iterators, and algorithms provided in the STL are beautiful. Simple things can be relatively simple in C++, when I use the right parts of it. But in that case C++ doesn't provide me many benefits--virtually zero. Python's immutable strings and hash-based mapping type can even be faster than C++ in some cases. But I simply don't need efficiency. My longest running program takes less than 3 seconds to complete, and that's plenty fast for my purpose. The archaic separate compilation/linking model and the complication of static type declarations seem a pain in the ass that I don't benefit very much from. The one program I needed that was just horribly slow in Python involved trying to match up names in a fuzzy manner between two systems, to help me find students who couldn't be bothered to get their own social security number correct. This took nearly 20 minutes to run. But, ummm.., it turned out I was doing the wrong thing. Even students who can't remember their SSN mostly got their phone number or email address correct, it turns out. There's a tall stack of stuff *not* written in Python that I depend on, though: Python itself, sqlite3, gvim, Windows 7, etc. At this point I feel hopelessly unqualified to write any of that stuff, but if I had to, I'd need to resuscitate my C++, or at least my C, as a starting point. There's a growing number of projects hoping to bridge an apparent gap between Python and C. C++ can be regarded as an early effort--so early that there was no Python to measure against. Maybe it would've turned out better if there had been. ;) Python developers are filling part of the gap with libraries, e.g., numpy and scipy. I could take advantage of numpy by installing Pandas; I'll learn Pandas long before I resort to C++. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Thursday, August 21, 2014 6:24:18 PM UTC+5:30, David Palao wrote: Hello, I consider myself a python programmer, although C++ was one of the first languages I learned (not really deeply and long time ago). Now I decided to retake C++, to broaden my view of the business. However, as I progress in learning C++, I cannot take out of my head one question Why to use C++ instead of python? It is not ranting against C++. I was/am looking for small-medium projects to exercise my C++ skills. But I'm interested in a genuine C++ project: some task where C++ is really THE language (and where python is actually a bad ab initio choice). The usual argument in favour of C++ (when comparing to python) is performance. But I'm convinced that, in general, the right approach is python-profiling-(extension/numpy/Cython/...). At least for a python programmer. I might be wrong, though. This is, perhaps, a bit off-topic, but I really want to know the thoughts of experienced python programmers on it. Not C++ but (mostly) C: http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html And someone opposed to that view: http://dieswaytoofast.blogspot.in/2013/01/why-i-grown-to-loathe-c.html I said something about it here: http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 2014-08-21, David Palao dpalao.pyt...@gmail.com wrote: Why to use C++ instead of python? 1) C++ is the only language available for your platform, and for some reason you are unable to build Python from source. 2) You need money, and the only person willing to pay you says use C++ and won't listen to reason. 3) You're a masochist. That's all I can think of... -- Grant Edwards grant.b.edwardsYow! I want a WESSON OIL at lease!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Thank you for the interesting answers. Just a clarification. Actually for the scope of this question, I consider C and C++ quite different. At least when they are properly used (eg, you could use C++ as a better C, but this is not C++ in its full glory). In my opinion, if all that you want is performance, coding critical parts in C or Frotran should be enough. Or even Cython. As far as the fraction of code that turns out to be critical is relatively small. But C++ is a monster compared to C. And I realize it requires a huge amount of time and practice to master it. The question is whether is it worth as a generic approach or not (*). I tend to think that it isn't that useful. Best, David (*) as some of you already mentioned, you could need C++ for joining a specific project, for instance. But that would not imply anything about how well suited is C++ for that particular project. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 08/21/2014 07:39 AM, Burak Arslan wrote: For my day job, I chose Qt on C++ for a classic desktop app that needs to be deployed on Windows (among other platforms) with an installation package that is as small as possible. All I need to do deployment-wise is to create an NSIS script putting a couple of DLL's and my executable in a folder in %ProgramFiles% and a shortcutin start menu. The full package is 5 megs and the update archive is pushing half a megabyte. I was also back to C++ after a number of years of exclusive web dev with Python and Javascript. C++11 is just *sweet*, I'd never imagined I'd enjoy doing non-computer-sciencey work with C++. Definitely second the idea of using Qt and C++ to build something. Qt is natively C++, so it's most at home there. Qt works fine in other languages, like Python, but it's not a perfect fit there because Qt is based on the C++ object model. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Le 21/08/2014 15:40, Chris Angelico a écrit : On Thu, Aug 21, 2014 at 10:54 PM, David Palao dpalao.pyt...@gmail.com wrote: Why to use C++ instead of python? This is, perhaps, a bit off-topic, but I really want to know the thoughts of experienced python programmers on it. No, it's a fair question. Why are we all here? The fact is, there's not a huge amount of reason left. If you're linking against a C++ API, you may find it easiest to do the whole program in C++, rather than use something like Cython (which, as far as I'm aware, is C-only) or write a two-part project. And obviously if you have an existing C++ codebase, then porting it has costs, and maintaining it is probably better. But for the most part, I would strongly recommend starting a project in a high level language like Python unless there's a really compelling reason to do otherwise. C++ has, of late, been growing a number of features that belong in higher level languages; but if you want those sorts of features, why not just grab Python or Pike or something and save yourself the trouble? For information, Cython works with C++ now: http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html. Joseph -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On Fri, Aug 22, 2014 at 4:05 AM, Joseph Martinot-Lagarde joseph.martinot-laga...@m4x.org wrote: For information, Cython works with C++ now: http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html. Now isn't that cool! Every time Cython gets discussed, I get a renewed desire to learn it. Trouble is, I don't have any project that calls for it - there's nothing I'm desperately wanting to do that involves both Python and C/C++. Anyone got any suggestions? :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs. C++11
On 15.02.2012 08:18, Tim Roberts wrote: sturlamolden sturlamol...@yahoo.no wrote: There are bigsimilarities between Python and the new C++ standard. Now we can actually use our experience as Python programmers to write fantastic C++ :-) This is more true than you might think. For quite a few years now, I've been able to do an almost line-for-line translation of my Python programs to C++ programs. (Microsoft has had a for each extension for a while that made this easier.) I disagree. Unicode support comes for free with Python3+ while C++ it still is a piece of crap (or something that you'll have to pass to external libraries). The C++ standard library is nowhere nearly as densely packed with features than Python's. For every little thing you need some external dependencies. Language semantics aren't enough to translate one language into another. Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. C++11
sturlamolden sturlamol...@yahoo.no wrote: There are bigsimilarities between Python and the new C++ standard. Now we can actually use our experience as Python programmers to write fantastic C++ :-) This is more true than you might think. For quite a few years now, I've been able to do an almost line-for-line translation of my Python programs to C++ programs. (Microsoft has had a for each extension for a while that made this easier.) -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Python vs. C++11
There are bigsimilarities between Python and the new C++ standard. Now
we can actually use our experience as Python programmers to write
fantastic C++ :-)
Here is a small list of similarities to consider:
Iterate over any container, like Python's for loop:
for (type item: container)
Pointer type with reference counting:
std::shared_ptr
Python-like datatypes:
tuple std::tuple
list std::vector
std::list
std::stack
dict std::unordered_map
set std::unordered_set
complex std::complex
deque std::deque
lambda[name](params){body}
heapq std::heap
weakref weak_ptr
str std::string -- unicode, raw strings, etc work as Python
Other things of interest:
std::regex, std::cmatch
std::thread thread api versy similar to Python's
std::atomic datatype for atomic operations
std::mt19937 same prng as Python
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. C++11
On Feb 13, 4:21 am, sturlamolden sturlamol...@yahoo.no wrote: There are bigsimilarities between Python and the new C++ standard. Now we can actually use our experience as Python programmers to write fantastic C++ :-) And of course the keyword 'auto', which means automatic type interence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
John J. Lee wrote: I guess the same is true of Python in some respects: it's still incrementally changing (more than C++, I guess), and isn't all that much younger than C++ (around 15 and 23 years old respectively). But C++ is almost entirely backwards compatible with C, which adds another dozen years or so... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Randall Parker [EMAIL PROTECTED] writes: [...] Also, a lot of C++'s flaws flow from the fact that it is old and grew in lots of increments. That was a deliberate decision on the part of C++'s designers!-) I guess the same is true of Python in some respects: it's still incrementally changing (more than C++, I guess), and isn't all that much younger than C++ (around 15 and 23 years old respectively). In my experience the overhead of explicitly deleting objects in C/C++ is not the big burden that some argue here is the biggest reason to use Python instead of C++. Should we be entirely surprised that from somebody from a engineering / numerical analysis background has that experience? Fortran 77 didn't even *have* a standard way to do dynamic memory allocation, did it? I certainly do think garbage collection is useful in that context, though... John -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Randall Parker [EMAIL PROTECTED] writes: [...] The code I'm writing in Python is a test executive to test embedded C code. Then tests get written in Python that the test executive processes. No, I'm not going to write yet another layer of tests in order to compensate for shortcomings in the Python language. Yeah, despite being a fan of test-first, I don't write tests for tests either. That has been true when I've been testing numerical code written in both C and Python, for example. If I were writing any sort of test infrastructure code, however tiny, I would write tests for that code, regardless of the language. For those reasons, I don't see writing tests as compensating for shortcomings of Python. This discussion reminds me of statistics books that claimed that, just as a measurement without an error estimate was meaningless, so an error estimate without its own error estimate was also meaningless. By that logic, seems all measurement is meaningless :-) (please everybody note this is meant as a mildly amusing aside, not a point of argument!) It's also a pain to write unit tests, but it's much more rewarding than writing type declarations. Not only does it force you to think through the ramifications of changes, but you also document your intentions through your tests. I do not have time to write unit tests for the Python classes. I have plenty of unit tests to write in Python for the embedded C modules. When I run and hit a problem in Python I just debug it and fix it. That's a lot faster than writing unit tests. As somebody who has worked in both test-first and 'a smattering of tests' styles, I'm quite sure you're right: when you don't have lots of unit tests, writing them slows you down. The benefit to be had comes when making *changes* to code with *good* unit test coverage. We all know people whose 'pragmatism' sometimes operates on, um, a strictly local basis and neglects the impact on a wider scale. I think we usually fall into that trap when we fail to write unit tests. I'm open to the idea that the benefits depend heavily on the sort of code you're writing, though. John -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Randall Parker wrote: Magnus Lycka wrote: Randall Parker wrote: Also, compile time errors get caught sooner. They get caught before tests even get written. Not if you do Test Driven Tevelopment. Then you write the tests before you compile your target code! It's also my experience that the write test - write code - run test cycle in TDD with Python is often faster than the plain edit - compile cycle in C++. More extensive tests take longer, but so does linking of C++ code... Magnus, I see a problem with your argument: On the one hand you say that Python's lack of type declarations can be compensated for by Test Driven Development. But then you say Python has a bigger advantage in situations where requirements are not well defined. Well, when requirements are in flux and being explored during development it is a waste of time to write tests to test against nebulous requirements. TDD and poor requirements don't mix very well. Not at all. Agile development methods such as XP, where TDD is fundamental, were developed with the purpose of making to easy to handle changes late in the project. Embrace change as Kent Beck put it. Unit tests aren't really used to verify that a whole program system fulfils all requirements. They're there to verify that a small piece of code works as the programmer intended. To be effective when the requirements change, unit tests need to be fairly isolated, so that one requirements change usually don't affect more than a few tests. For each change in requirements, most existing requirements hold, and hopefully, the vast majority of tests would still run correctly. With a large set of automated unit tests, you can confidently change your code to fulfill the new requirements without breaking any existing functionality without noticing. As for changing argument types: But this is exactly the sort of situation where I find myself getting into trouble in Python. I have to change some type and I forget everywhere I've passed it or returned it. Strange. I very rarely have trouble with this. What happens when you run your tests? Surely things break in the cases where the type change cause trouble, and you get tracebacks that tell you exactly what and where you need to change things. The only difference compared to the compiler, is that it won't force you to change things in places where things still work as intended even though a type was changed. Or...don't you have automated tests? Ouch. If you (like me) feel a little lazy to write a lot of test scripts, you can use a test tool such as TextTest, that compares output between test runs, rather than forcing you to write lots of scripts with plenty of assertions. The effort required to get started is probably bigger there though. (I don't really know, it was all set up for me at work.) In C++ if I make changes the compiler is going to keep complaining and pointing out type clashes I've introduced due to changing a variable's type. Granted, it is a pain to change type declarations. But visiting those places often makes me think thru the ramifications of changes. It's also a pain to write unit tests, but it's much more rewarding than writing type declarations. Not only does it force you to think through the ramifications of changes, but you also document your intentions through your tests. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Magnus Lycka wrote: Or...don't you have automated tests? Ouch. If you (like me) feel a little lazy to write a lot of test scripts, you can use a test tool such as TextTest, that compares output between test runs, rather than forcing you to write lots of scripts with plenty of assertions. The effort required to get started is probably bigger there though. (I don't really know, it was all set up for me at work.) Magnus, The code I'm writing in Python is a test executive to test embedded C code. Then tests get written in Python that the test executive processes. No, I'm not going to write yet another layer of tests in order to compensate for shortcomings in the Python language. It's also a pain to write unit tests, but it's much more rewarding than writing type declarations. Not only does it force you to think through the ramifications of changes, but you also document your intentions through your tests. I do not have time to write unit tests for the Python classes. I have plenty of unit tests to write in Python for the embedded C modules. When I run and hit a problem in Python I just debug it and fix it. That's a lot faster than writing unit tests. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Randall Parker wrote: C++ provides ways to be type unsafe. Does that mean that C++ is type unsafe period? Most code in C++ is going to be type safe. Some programmers will never do dangerous casting. Others will do bad things with casts. Sure, but on the other hand, you are really on your own when you avoid the compile time type safety in C++. While you might get an exception in Python, which you can handle in your code, or at least get a traceback from, anything can happen in C++, from data corruption to core dumps. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Randall Parker wrote: I return objects in Python and in C++. In C++ I can see what their types are right on the m method signature. In Python I've got to write a comment on the line above it. Ouch! Don't do that! As you've noticed, it's not very maintainable. First of all, if you want to use Python well, embrace it's dynamic nature, don't try to restrain it! It takes some time to let go of the static thinking if one is used to it, but try. Just as lots of programming guidelines (e.g. Parna's Principle and The Law of Demeter) tells us that we should try to know and depend as little as possible on the details in other pieces of code, the duck typing behaviour in Python extends this one step further, to types. Without proper tests, this might cause more problems than it solves, but there is no excuse for not having proper automated tests for software you develop in the 21st century!!! You *don't* write an unmaintainable comment about what return type to expect, you write unit tests that shows you how to use each API that you implement. You run these tests often, fix them as soon as they break, and you encourage their use as documentation which describes through examples how to use you APIs. (Sorry about the imperative tone. It's your life after all, but don't blame Python for not fitting your style of development.) You should do that for statically typed languages as well. Knowing that you got the correct type back gives you no assurance that you got the right value! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Randall Parker wrote: Also, compile time errors get caught sooner. They get caught before tests even get written. Not if you do Test Driven Tevelopment. Then you write the tests before you compile your target code! It's also my experience that the write test - write code - run test cycle in TDD with Python is often faster than the plain edit - compile cycle in C++. More extensive tests take longer, but so does linking of C++ code... There is obviously not one way of development which is optimal in all situations. I've done development for space equipment as well as business software. In my experience, software requirements in e.g. aerospace industry are much more stable. The people responsible for requirements and specifications are engineers, not accountants, and they understand systems development. In typical application development, I'd say that the effort required to get a finished, reasonably reliable product is much smaller with Python than with C++. You might need more tests, but the effort spent on that is easily outweighed by the time saved by coding in Python instead of C++, Java etc. If the requirements are very stable, there is less need for the kind of flexibility and agility that Python provides. One of the big advantages with the dynamic typing in Python is that you get less tight coupling. For instance, if you have some kind of layered approach in e.g. C++, and a number of parameters are passed from one layer to the next in several steps, changing the type of one parameter will cause changes everywhere in the communication chain. In Python on the other hand, it's typically only in the end-points that type changes will have an impact. In many development projects, the appropriate requirements aren't clear from the outset of the project. The problem in the project is not to implement a number of well defined protocols in an optimal way, but to provide a solution that will support the business in an efficient way. Initially, the problem domain experts and the software developers are probably far away from each other in their view of the system, and while the customer knows the business purpose of the system, it's not at all clear how this will be achieved. With tools and methods that are rigid and don't support a flexible and experimental approach, discovering problems with requirements or analysis in the middle of the project, might lead to costly and disruptive rewrites or that the project sticks with a clearly bad solution to avoid the risks that a rewrite leads to in terms of cost, time and reliability. Sure, big requirements changes late in a software project will hamper the development whatever tools you use, but how much these changes costs can probably vary tenfold depending on tools and methods. With Python and an agile approach, a late change is usually much cheaper, so it's not as unreasonable to make this late change that makes the product much better. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Jay Parlar wrote: Well guess what: The *only* code you'll have to change is inside the function returning the object, none of the callers would have to change. That's completely different from C++, where you'll have to change not only the return type and the function, but you'll also have to change every single calling function to be aware of this new db object. And not just how the callers store the returned object, but also how they use that object. That's a LOT of work, for really no gain. Part of the problem is that both standard Python and C++ lacks the concept of defining an interface. Whether we deal with C++ or Python, we need to understand what we can do with a return value, or what kind of interface a parameter we send to a function needs to provide. In Python, this is implicit. The compiler doesn't force us to do the right thing, and a programmer can make a mess by doing it wrong. In C++ it's the opposite. By demanding a particular type, we restrain ourself to using a set of values which is much smaller than the logic calls for, or we can throw away all type checks by e.g. casting to void pointers. I don't have enough experience with languages that provide interfaces, such as Java, to understand how useful they are, but it's my impression that they are too cumbersome to use fully. As far as I understand, most Java APIs use types more than interfaces for parameters and return values. (I browsed the Java API docs at java.sun.com, and as far as I see, it seems the APIs always require parameters of distinct classes or types, and return values of particular types or classes.) I know that there have been attempts to provide interfaces in Python, and it seems Zope Interfaces are getting a decent following, but I don't think anyting like that will ever take the place that type declarations of all function and class declarations have in e.g. C++. It's too difficult to make interfaces so convenient and flexible that they could be used generally in Python without taking away a lot of power. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Jens Theisen wrote: Jay wrote: How much time in your C/C++ code is spent casting and trying to trick the compiler into doing something that it thinks you shouldn't be doing? Not much frankly. Though I have no doubt that there is a lot of code that does, but more so in older C++ code. I think the real difference between Python and C++ code in this respect is rather how easy it is to adapt the code to a change in requirements. How many lines of code of C++ or Python needs to be changed when you get a particular change request. There are some cases where the Python programmer will simply smile and say, that already works (well, he should probably write a test case and run that first), where the C++ programmer gets to do a lot of changes to his code. Usually, the difference is probably smaller than that, but the Python coder is probably less nervous about change requests (provided that he has proper automated tests)... There is probably more logical duplication in the C++ code, with different code snippets handling different cases where one set of Python code works with several differnt types. Changes in the semantics of these functions lead to changes in one place for the Python coder, and several changes for the C++ coder, which means a risk that a fix is partially implemented, and works in some cases but fails in others. Because in all of my own industry experience, it's been MUCH easier to jump into someone else's Python code than someone else's C++ code (and at my last job, I had to do a lot of both). I find Python to be much more self-documenting, because there's not so much scaffolding all over the place obfuscating the true intention of the code. I'm sure this depends a lot on what people are used to. I had to provide source code for inspection for a job interview, and the reviewers (who write both C++ and Python) said that they felt that my code was more difficult to understand than the other code samples (which were in C++ or Java). (I still got a job though.) This might be because I'm a crappy programmer, or because the other people typically handed in some university project they had been fully in charge of and written for the purpose of examination, while my code had been changed over a few years based on the whim of a fairly non-technical customer, and only ever read by me. It might be because my code dealt with a more complex problem, or at least something that was difficult for the reviewers to grasp. It could also be because the reviewers were more used to C++. They said that they felt that the lack of .h-files made it difficult for them to get an overview of the code, but it didn't seem that they used anything like pydoc to get a picture of the API. In other words, your milage might vary, and the choice of programming language is just one among many factors that influence how easy it is to read code. Having said that, I agree: It's typically easier to get into someone else's Python code. Particularly when so-called C++ code is really C with lots of globals, no classes and 63 pages of functions (many of which are several pages long, the longest being 13 pages) which often modify the global variables. (Yes, I have such a nice thing on my table now. Happily, I don't have to maintain it. I'm writing a Python program that partially does the same thing, but I doubt this program will help me understand the problems involved, or help me find optimal solutions...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Magnus Lycka wrote: Randall Parker wrote: Also, compile time errors get caught sooner. They get caught before tests even get written. Not if you do Test Driven Tevelopment. Then you write the tests before you compile your target code! It's also my experience that the write test - write code - run test cycle in TDD with Python is often faster than the plain edit - compile cycle in C++. More extensive tests take longer, but so does linking of C++ code... Magnus, I see a problem with your argument: On the one hand you say that Python's lack of type declarations can be compensated for by Test Driven Development. But then you say Python has a bigger advantage in situations where requirements are not well defined. Well, when requirements are in flux and being explored during development it is a waste of time to write tests to test against nebulous requirements. TDD and poor requirements don't mix very well. As for changing argument types: But this is exactly the sort of situation where I find myself getting into trouble in Python. I have to change some type and I forget everywhere I've passed it or returned it. In C++ if I make changes the compiler is going to keep complaining and pointing out type clashes I've introduced due to changing a variable's type. Granted, it is a pain to change type declarations. But visiting those places often makes me think thru the ramifications of changes. Also, I've been on projects where the whole purpose of my code has been to test equations and control laws (this was for space probes to places like Eros and Saturn btw). We were certainly doing test driven development in one sense. But the assumption the systems engineers wanted to make was that the algorithms were written correctly in code and that if the system didn't behave correctly then the problem was in the algorithms, not in the code. We therefore were not in a position to do test drive development on the code itself. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
In article [EMAIL PROTECTED], ... Granted, it is a pain to change type declarations. I see it is time for the bi-monthly reminder that C++ is not the ideal example of strong static typing, unless you just want to make it look bad. Cf. Hindley-Milner type inference. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Magnus Lycka wrote: In C++ it's the opposite. By demanding a particular type, we restrain ourself to using a set of values which is much smaller than the logic calls for, or we can throw away all type checks by e.g. casting to void pointers. The main reason for evading the type system in such a severe fashion in C++ is to break out of class hierarchies (noting that downcasting is achievable in a slightly safer fashion). Ideally, one would design class hierarchies in such a way that such break-outs are avoided, but this can involve a lot of argument/discussion about design/architecture that is mostly unnecessary with Python. I don't have enough experience with languages that provide interfaces, such as Java, to understand how useful they are, but it's my impression that they are too cumbersome to use fully. My experience is the opposite: if one follows the recommended practices with Java, the flavour of object-orientation employed is more interface-oriented than anything else. Ages ago, there was a trend towards describing class relationships using conformance rather than inheritance; that there's still an incentive to rely more on inheritance in Python-based systems has a lot to do with Python's arguably better support for inheritance than Java, that doing away with multiple inheritance in Java forced people to look at other ways to model their information, and that conformance is typically dynamic and implicit in Python anyway. As far as I understand, most Java APIs use types more than interfaces for parameters and return values. (I browsed the Java API docs at java.sun.com, and as far as I see, it seems the APIs always require parameters of distinct classes or types, and return values of particular types or classes.) I can't comment on most Java APIs, but if you look at established packages like java.io and java.util, both are heavy on interface usage. I know that there have been attempts to provide interfaces in Python, and it seems Zope Interfaces are getting a decent following, but I don't think anyting like that will ever take the place that type declarations of all function and class declarations have in e.g. C++. It's too difficult to make interfaces so convenient and flexible that they could be used generally in Python without taking away a lot of power. Generally, interfaces provide a fairly convenient means of expressing the capabilities of objects whilst providing information that can be useful, in conjunction with a suitably designed runtime environment, in the generation of fairly well-optimised code. In a sense, what you say about taking away a lot of power is highly appropriate: by imposing an interface system on Python, it's quite likely that one could gain performance and a certain measure of predictability whilst losing certain dynamic aspects of the language. I personally wonder whether it's worth speculatively imposing such prescriptive measures whose burden is on the programmer and where the programmer is likely to spend a lot of time trying to work around them. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Donn, More generally: One must keep in mind that advantages and disadvantages of specific implementations of language concepts are not always indications of flaws in those concepts. Real languages have real flaws from bad design choices which cause them to fall short of what those languages could achieve. My own experience with Python and C++ is that C++ could be improved to gain it at least some of Python's advantages. After programming in Python for a while and then switching back to C++ my reaction is that C++ needs some features added to its syntax and to its RTL to make it easier to do some of the things that are much easier to do in Python. Also, a lot of C++'s flaws flow from the fact that it is old and grew in lots of increments. In my experience the overhead of explicitly deleting objects in C/C++ is not the big burden that some argue here is the biggest reason to use Python instead of C++. I find Python easier to use more for how it implements lists, dictionaries, standard libs for things like sockets, and other areas which require more work and less portability in C++. C++ needs a new standard toolbox and some new keywords to make loops and other things easier to do. Donn Cave wrote: In article [EMAIL PROTECTED], ... Granted, it is a pain to change type declarations. I see it is time for the bi-monthly reminder that C++ is not the ideal example of strong static typing, unless you just want to make it look bad. Cf. Hindley-Milner type inference. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
In article [EMAIL PROTECTED], Randall Parker [EMAIL PROTECTED] wrote: ... More generally: One must keep in mind that advantages and disadvantages of specific implementations of language concepts are not always indications of flaws in those concepts. Sure. And of course, the nominal topic wasn't really the concepts, but more about two actual languages, so in that respect my point was a little off base - it's only germane to the little religious war that usually comes along at this point. The endlessly rehashed arguments in that context should be about whether you can test everything, whether types convey semantics, etc. Let us forget about whether explicit typing is too much overhead, since it isn't required in principle. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Magnus Lycka [EMAIL PROTECTED] writes: Sure, but on the other hand, you are really on your own when you avoid the compile time type safety in C++. But it's almost impossible to avoid. Does *p point to a valid object, or to unallocated memory? C++ has no way to tell this at compile time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Op 2006-01-30, Magnus Lycka schreef [EMAIL PROTECTED]: Donn Cave wrote: If we give him credit for having some idea of what he's talking about, then we could perhaps read his encourages as makes trivially easy. These two languages are in such different levels with introspection that it seems kind of disingenuous to me to make this argument, frankly. My impression when I compare Python with e.g. Java is this: Java is designed to make to difficult to do the wrong thing. Python is designed to make it easy to do the right thing. That seems to depend on which part of the community you are talking to. Some do argue that some features shouldn't be included in the language because the risk of bugs by those who don't understand how to use it properly, is too high. That even seems to be the way the BDFL feels about things. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Alex Martelli wrote:
The but without declaration it can't be self-documenting issue is a
red herring. Reading, e.g.:
int zappolop(int frep) { ...
gives me no _useful_ self-documenting information about the role and
meaning of frep, or zappolop's result. The code's author must obviously
add a little comment here to clarify -- and in that little comment,
adding the information about type, if at all relevant, is an obvious
task.
Yes, one can use such simple types that the types do not tell you that
much. They do tell you something though. The arg and return types are
not list structures for example. They aren't floats either.
However, C/C++ at least provide a way to make types tell you far more.
For example, one could declare enum types:
typedef enum MyArgType
{
// a bunch of enum const names here
} MyArgType;
typedef enum MyResultType
// another bunch of enum const names
} MyResultType;
Then your example above becomes
MyResultType zappolop(MyArgType frep) { ...
and that's a lot more insightful.
I return objects in Python and in C++. In C++ I can see what their
types are right on the m method signature. In Python I've got to write
a comment on the line above it. If I change what type I return and
forget to change the comment then the code isn't correctly documented
anymore. I've done recently and found out with a runtime error while
testing the Python. In C++ if I'd changed the return type the compiler
would have told me if I didn't use it that way somewhere else.
There are a lot of stages at which to reduce the chance of bugs. While
coding an editor can give you more help with code completion if you
have more static typing. At compile time the compiler can tell you
about errors if it knows the types you are using.
I use PyChecker and PyLint and while they are incredibly helpful (and
I'm grateful to their authors just as I am to Python's developers) they
do not tell me as much as Borland's C++ compiler does. I get more
runtime errors with my Python code than with my C++ code.
Still, I find Python useful and better than C++ in some situations.
But I wish it provided better options for allowing me to indicate types
so that more errors could get caught sooner and so that editor code
completion could be smarter.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Jay, The point of doing compile time and test time checking is the same reason militaries use layered defenses: More problems get caught. I've written tons of software tests and architected a testing system for an entire aircraft. I've also watched lots of errors get by tests. Also, compile time errors get caught sooner. They get caught before tests even get written. Plus, tests become just another layer that needs testing. They also become another layer that can get out of synch with the rest of the software. As for casting away type safety: Sure, you can make C/C++ type unsafe. But that's optional. You can use the type safety if you want to. Most peope use the compiler's type checking because it is more effort to cast away type checking than it is to use it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Randall Parker wrote: The point of doing compile time and test time checking is the same reason militaries use layered defenses: More problems get caught. I've written tons of software tests and architected a testing system for an entire aircraft. I've also watched lots of errors get by tests. Hmm... with that analogy, I would have to say that most people who strongly advocate static typing and compiler tests are really relying solely on their perimeter guards. They seem to think that provides sufficient defense, and forget to finish the fortress walls. That is, they often don't do adequate tests. Those of us who have really strong fortress walls might sometimes be willing to forego the perimeter guard, perhaps unwisely, but at least we know immediately when we're under attack. Plus, tests become just another layer that needs testing. They also become another layer that can get out of synch with the rest of the software. Not if you are doing test-driven development, at least. In that case by definition if you're out of sync, it's the code which is failing the test because the test defines what the code should be doing. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Randall Parker wrote:
Alex Martelli wrote:
The but without declaration it can't be self-documenting issue is a
red herring. Reading, e.g.:
int zappolop(int frep) { ...
gives me no _useful_ self-documenting information about the role and
meaning of frep, or zappolop's result. The code's author must
obviously
add a little comment here to clarify -- and in that little comment,
adding the information about type, if at all relevant, is an obvious
task.
Yes, one can use such simple types that the types do not tell you that
much. They do tell you something though. The arg and return types are
not list structures for example. They aren't floats either.
However, C/C++ at least provide a way to make types tell you far more.
For example, one could declare enum types:
typedef enum MyArgType
{
// a bunch of enum const names here
} MyArgType;
typedef enum MyResultType
// another bunch of enum const names
} MyResultType;
Then your example above becomes
MyResultType zappolop(MyArgType frep) { ...
and that's a lot more insightful.
Except once a type starts to get a little bit complicated, you're not
going to be able to keep it in your head, and you'll have to go back
to the C++ definition of the type anyway when you want to know what it
does. Much like you'd have to go back to the Python source of a class.
(This is of course assuming that you put a comment in your Python code
saying that a certain kind of class is expected. I find it's obvious
about 80% of the time what's expected).
I return objects in Python and in C++. In C++ I can see what their
types are right on the m method signature. In Python I've got to write
a comment on the line above it. If I change what type I return and
forget to change the comment then the code isn't correctly documented
anymore. I've done recently and found out with a runtime error while
testing the Python. In C++ if I'd changed the return type the compiler
would have told me if I didn't use it that way somewhere else.
Yeah, but you can't *just* change the type you're returning, and expect
to be done. You'll also have to change the source code of the function
to actually return something of that type. And you'll have to change
all the places where the function is called, to make sure that the
caller is storing the result in an appropriately typed variable.
Often times in Python, the thing you're returning is useful because of
duck-typing, not because it's actually of a particular class. Maybe in
some piece of code, you're returning a file() object, and all the
callers really care about is the ability to do a read() and write() on
that object.
Maybe later in the lifecycle of your program, you no longer store
things in the filesystem directly, but in a database. You'd have to
change your function such that it no longer returns a file() object,
but some object that instead is connecting to a database. But you still
only need to call read() and write() on it.
Well guess what: The *only* code you'll have to change is inside the
function returning the object, none of the callers would have to
change. That's completely different from C++, where you'll have to
change not only the return type and the function, but you'll also have
to change every single calling function to be aware of this new db
object. And not just how the callers store the returned object, but
also how they use that object. That's a LOT of work, for really no
gain.
And that's the ENTIRE point (as I see it) of the Python typing system.
Usually you know what you want to do, and you shouldn't have to fight
to do it.
If you haven't heard the term duck typing before, Wikipedia has a
decent page on it, and a simple Google search will return many more
results.
There are a lot of stages at which to reduce the chance of bugs. While
coding an editor can give you more help with code completion if you
have more static typing. At compile time the compiler can tell you
about errors if it knows the types you are using.
Yeah, but it can only tell you about type errors, and those aren't
really critical. They're the kind of error that takes a second to fix
when found. Yet *how much* time is often spent fighting with a compiler
to make it accept the types you actually want to use?
I use PyChecker and PyLint and while they are incredibly helpful (and
I'm grateful to their authors just as I am to Python's developers) they
do not tell me as much as Borland's C++ compiler does. I get more
runtime errors with my Python code than with my C++ code.
That's to be expected, but the time needed to get to a runtime error is
so much less in Python (especially if you've got good unit/integration
tests). I recommend you bring IPython into your development tools, so
you can easily import small parts of your code and hand test them in
isolation.
Still, I find Python useful and better than C++ in some situations.
But I wish it provided better options
Re: Python vs C for a mail server
Jay wrote: You can do both, but why? *Especially* in a language like C++, where thanks to pointers and casting, there really isn't any type safety anyway. How much time in your C/C++ code is spent casting and trying to trick the compiler into doing something that it thinks you shouldn't be doing? Not much frankly. Though I have no doubt that there is a lot of code that does, but more so in older C++ code. How does type safety tell you anything about the current usage of your program? Quite a bit; of course, it's doesn't cover everything and clearly testing the semantics is still needed, but a lot of what code is used in what way is described by the type system. And I admit that I'm used to use the type system as documentation of what's going on. And unit tests *might* not tell about the current usage, but integration tests certainly do. Of course tests will cover a lot what static typing does and more. I'm just claiming that they can support each other. I don't think I've ever seen anyone advocating calling a function like getattr(obj foo + bar)(). You can do some very powerful things with getattr, thanks to Python's dynamic nature, but I don't think anyone is recommending calling a function like that. A lot of people got me wrong on that, please see Paul's postings. I really didn't mean that literally. And is that fear based simply on feeling, or on actual experience. The former, that's why I did start this branch of the thread, though I'm already regretting it. Because in all of my own industry experience, it's been MUCH easier to jump into someone else's Python code than someone else's C++ code (and at my last job, I had to do a lot of both). I find Python to be much more self-documenting, because there's not so much scaffolding all over the place obfuscating the true intention of the code. That really depends on who's code you're looking at, as in any language. I can believe there are more C++ obfuscaters out there than ones for Python. I usually have little problems jumping into C++ code of other people but the principle reason for that will be that the people I'm working with have a very clean and expressive coding style. You need to look at doctest: http://docs.python.org/lib/module-doctest.html With doctest, tests are EXACTLY where the code is. I've used doctest with incredibly successful results, in industry. That's indeed a good point for Python. Reference counting by itself is not necessarily sufficient (because of circular references). That's why even Python, with its reference counting based system, has additional capabilities for finding circular references. Whenever I encountered the need for circular references it was because an object, that was in some sense owned by another, needed a pointer back to it's owner. That solved easily with non-owning C-style pointers or weak pointers. If you have an example where this is not sufficient, I'd be *very* keen on hearing it (it may be easy, I don't know). I believe that Alex's official job title at Google is Uber Technical Lead. I'm sure I'll quickly be corrected if that's wrong, but trust me (and everyone else who's spent significant time reading c.l.p.) that Alex Martelli knows what he's talking about. You seem to be thinking that I was ironic. That was certainly not my intention. I was just trying to minimise the amount of flames I'll be getting. A lot of your arguments are the very typical arguments that people levy against Python, when they're first around it. And that's fine, most people go through that. They are taught programming in C++ or Java, and that that *that* is the way you're supposed to program. Then they see that Python does things in different ways, and automatically assume that Python is doing it wrong. I'm sorry to hear this, and whilst I'm certainly lacking experience in Python, I'm not one of those people. All I can say is that if you spend time with Python (and more importantly, read quality, well-established Python code that's already out there), you'll see and understand the Python way of doing things. I will. Jens -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Paul wrote: Or should I be looking for some other context here? Three people were looking at the wrong one, thanks for putting this right. I really should not have given my point that briefly. Jens -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
But languages that share some weakness typically do not share it equally. Three languages can have some way to do X (which some might find undesirable while others find it great) but two of the languages might make it easy to solve problems without ever doing X while the third language might make it impossible or at least very difficult to solve problems without doing X. C++ provides ways to be type unsafe. Does that mean that C++ is type unsafe period? Most code in C++ is going to be type safe. Some programmers will never do dangerous casting. Others will do bad things with casts. I really think one has to factor in probabilities rather than state comparisons between languages in simpler terms. I also think that the number of ways problem domains differ that affect language choice varry in a lot more ways than, say, whether they have garbage collection built in. Maybe in Google where the coding is primarily for servers the need or lack thereof for explicit control over memory allocation is by itself reason enough to say yes or no to C++. But in other companies solving very different sets of problems (e.g. embedded devices with no operating system or embedded devices with limited RAM or limited CPU or an OS with few languages available) a lot of other factors play in the equation. Alex Martelli wrote: The context is: can any other language be different in this respect? Only by not allowing *any* way to get symbols dynamically, and therefore by substantially reducing the real-world cases in which it's usable. C++ (with dlopen/dlsym and equivalent libraries on other platforms, with dynamic_cast, ...) and Java (with 'reflection' etc) do afford this functionality, albeit in more cumbersome ways than Python. Therefore, if the inability to verify that a function named 'foobar' is in fact never called anywhere is a weakness, it's a weakness shared by all of these languages. The originator of this thread appeared to assume that it was a weakness of Python and not of C++... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Volker Grabsch wrote: Any programming language allows you to do strange/stupid stuff. But none of them encourages it. One word: Intercal. :-) -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs C for a mail server
Donn Cave wrote: If we give him credit for having some idea of what he's talking about, then we could perhaps read his encourages as makes trivially easy. These two languages are in such different levels with introspection that it seems kind of disingenuous to me to make this argument, frankly. My impression when I compare Python with e.g. Java is this: Java is designed to make to difficult to do the wrong thing. Python is designed to make it easy to do the right thing. Designing the language so that potentially problematic constructs are obscure and difficult to do is not considered a virtue in the Python community. If something is difficult to use, people will make more mistakes trying to use it. The right design choices should be actively encouraged by making them easy and accessible, not by making the alternatives hard. -- http://mail.python.org/mailman/listinfo/python-list
