Why Python?

[chan] bitmessage
Aug 7 10:33

Why is BM written in Python? I understand that it is safer wrt memory management issues which C and C++ are notorious for and it runs on all systems that have Python. But why not Tcl/Tk or Java?

[chan] bitmessage
Aug 7 15:36

because the dev knew python best. why the fuck do you care? Don't like it? Then port it to some language that you know. Stop cribbing.

[chan] bitmessage
Aug 7 22:57

As other experienced Devs here have pointed out, several times, the effort in coding directly in C/C++ is unlikely to yield any significant improvements worth the enormous effort in recoding. cpython can be built highly optimized for specific environments if you don't mind the effort in building the tools that write the privacy tools. It is an abstraction that provides enormous productivity gains and least distraction from low level coding issues. As the name suggests, it is the python implementation ( a higher level abstraction ) built *IN* C/C++. Lots of luck coding in "Safer" languages, like ADA; even if you have a generous government military budget to do it with, it will probably fail to deliver in other ways. Why custom build cpython? To get the most recent security fixes and bugfixes, and to select exactly what ssl/tls codebase you run at the sharp end on hostile network connections. From memory there are quite a few mercurial repository commits to python 2.1.13+ that wont be seen in packaged distro python implementations for quite some time: memory fragmentation improvements and tls timing improvements as but two examples. As someone that sat in on many OxBridge University academic seminars with visiting specialists involved in java efficiency and security tradeoffs I can tell you right now that java would be a lousy rebase alternative, and also not worth the effort that porting the present PyBitmessage implementation would involve. The Biggest objection that I have to Python in the context of this project are the daft decisions in Python3 that effectively make many projects impossible to convert to later versions of 3.x GUI "widgets" being just one example. I have a problem security wise with most languages that use autotype conversions internally to make programming easier. Complex specifications (such as UTF) always have implementation grey areas that are ripe for code abuses ( run fuzzing tools on those code modules for nasty surprises ). The changes to string handling in Python3 do offer smaller grey areas to attack, but I have no appetite to learn two parallel coding approaches to string handling. Python2 codebases and development are pretty much here to stay and I do feel sorry for the poor Barstewards that have to code both professionally, and will be lumbered with this misery for most of their programming careers - maybe more than half of their productive years if just starting out recently! This fact alone should be sufficient to lose Python its "market share" as better language implementations evolve into mainstream use; ones that promise easier continuity and experience "re-use" - not just code re-use. I hope that I have provided a little less noise and some insight. There are open access references to the fine details of java and python mentioned here for the inquisitive if you search for them. *PLEASE do NOT bait the Developers* This project almost stagnated once. I for one am extremely grateful that Peter Surda, and others have pitched-in rather than stand on the sidelines bitching but not contributing anything useful. What they are doing is HARD WORK, with little prospect of any reward in the short to medium term. I'm just cruising in their wake trying to learn a little about how the best pythonistas operate. Personally, I've no chance of ever reaching their level of competence, no matter how much time I divert to that end. Mere "Thanks" are completely inadequate. When you work at the bleeding edge, as they are doing, with real-time complex network code, you WILL be making spectacular mistakes as part of the learning process. They can spend what little time they have blogging about it all and media-whoring, but then they wouldn't have ANY time to code. It is irritating to find that things do not work as the boolean selections might suggest in the sections of code you've altered. Or configuration options that do not behave as expected. Been there MANY times myself since 2014 :- Tough. *Get over it*. The polite thing to do is send a synopsis of your issue by private message and find out WTF went wrong BEFORE going public with a Hissy Fit. Everybody Loses if you do that. I've annoyed these guys enough with distractions privately, but always received a polite and reasoned response as a gesture because of the courtesy I extended by starting out in Private. We need a Benevolent Dictator to decide the best direction the code must take. Its better that the more difficult exchanges are attempted privately first. Then the public side sees the compromise without all of the noise and bad humour. All thats left after that is to decide the best form of funny walk and salute to use at events where you meet in person ;-)

[chan] bitmessage
Aug 8 00:39

> the daft decisions in Python3 that effectively make many projects impossible to convert to later versions of 3.x Screw python and the python leaders. They won't let you use brackets instead of indents, they messed up the syntax into obscurity with the upgrade from 2.7 to 3.x, which caused mountains of 2.7 code to become obsolete. Most of the problems come from nobody looking at the big picture before they decide to reinvent the wheel. Most of my debug time in Python is finding and fixing indentation problems. Everyone in the programming world knows better than to use indentation as a syntax.

[chan] bitmessage
Aug 8 00:56

> But why not Tcl/Tk or Java? Java? Are you kidding? One of the slowest development times of any language? Tcl / Tk code for anything larger than an egg timer becomes impossible to understand or maintain. Tcl is an amazing language that allows really slick solutions, but any large codebase is unmaintainable. Pascal would be an improvement, and reads similar to Python, but has little community support and only a fraction of the libs of Python. It is less cryptic than C, runs as fast as C binaries, and is still used religiously by many large companies because of how much work time it saves--until you need a library that does not exist. How about Objective C? Using the reflective syntax features would be great for cryptographic logic, still close to regular C speed.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Aug 8 04:34

Bitmessage was already in Python when I joined the project so I didn't really have a choice there. There appear to be some low-level things (string handling, concurrency with threads) which I am unhappy about and find slow in Python, and am pretty sure would be faster in C. I did a lot of profiling in the current release cycle so I have a much better understanding of where the bottlenecks are. That being said, I think most of this can be worked around. For example the network subsystem can be in the future switched from multithreaded queues to multiprocessing queues, which will avoid the GIL bottleneck and gain better scalability. I'll do that when it makes practical sense. The string handling performance can probably be worked around as well. Sqlite interface can be switched from a queue to direct calls on systems where sqlite has concurrent access support compiled in. Especially older versions of python have inflexible SSL configurability (it has been improved in python 2.7.9). Similarly, most of this can probably be worked around, for example when I add authentication to TLS, that should allow python < 2.7.9 to act as a TLS server. I'm not sure regarding TLSv1.2 support in python < 2.7.9 but will have to examine it as Debian recently announced they are disabling TLSv1.0 and 1.1 support in shipped OpenSSL and this may prevent nodes with older python versions connecting with nodes running new Debian. I don't like java but can't say why exactly. Maybe the complicated build environment and that it's slow to start? Dunno. Anyway there is now a java implementation of Bitmessage called Pechkin, developed by Alexandr Fenenko: https://sourceforge.net/projects/pechkin/ Peter Surda Bitmessage core developer

[chan] bitmessage
Aug 8 05:13

much of bitmessage could be refactored with NUITKA, the python compiler. It generates very efficient machine code and gives much better performance enhancements than cython. What is Nuitka The TL;DR ... Nuitka is a Python compiler. It's fully compatible with Python 2.6, 2.7, 3.2, 3.3, 3.4, and 3.5. You feed it your Python app, it does a lot of clever things, and spits out an executable or extension module. Free license (Apache). Okay I'm hooked! Tell me more! Now Right now Nuitka is a good replacement for the Python interpreter and compiles every construct that CPython 2.6, 2.7, 3.2, 3.3, 3.4 and 3.5 offer. It translates the Python into a C program that then uses libpython to execute in the same way as CPython does, in a very compatible way. It is somewhat faster than CPython already, but currently it doesn't make all the optimizations possible, but a 258% factor on pystone is a good start (number is from version 0.3.11). It's in ubuntu repos. $ apt-get install nuitka NUITKA(1) User Commands NUITKA(1) NAME nuitka - the Python compiler SYNOPSIS nuitka [--module] [--execute] [options] main_module.py

[chan] bitmessage
Aug 9 01:34

> How about Objective C? There'd go our Wandows support. > Java? Are you kidding? One of the slowest development times of any language? You can sidestep this by using another language on the JVM--maybe Scala. Sure the systax'll make your eyes bleed, but SPEEEEEEEEEED!!!!!11one Regardless of the language, is anyone up for removing the Application GUI and just having a web interface on localhost? It'd be really nice for modularity.

[chan] bitmessage
Aug 9 01:55

> Regardless of the language, is anyone up for removing the Application GUI and just having a web interface on localhost? I already started the framework for a browser client. I created a secondary channel on the SimpleXMLRPCServer that serves the http content to the browser and accepts both XML and JSON API calls back and forth between PyBitmessage and the browser (or even cUrl) using straight JavaScript (no jQuery). With that set up I stopped. I want to wait until streams are implemented before I do all that work. We already have the QT GUI. There's no use in me coding a JS GUI until PyBitmessage is a bit more mature. Streams have to be working and able to scale the traffic to a massive user base (at least a few million peers) before I want to put effort into a fluffy and unnecessary client.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Aug 9 07:12

PyBitmessage can run in a headless mode and use the API to provide an alternative UI. Although I think the API could be enhanced as some features aren't available there. I believe the current API is compatible with browsers (there were some incompatibilities but I think someone suggested a fix and it was merged). So if someone provided a Web UI that I could bundle, I'd be very happy. Similarly for an IMAP interface, I was unable to find a IMAP server library for Python. Peter Surda Bitmessage core developer

[chan] bitmessage
Aug 9 10:29

Pff. Fuckin AAPL walled garden shite.

[chan] bitmessage
Aug 9 14:28

I think that it needs a RAD minimal GUI that has multi-platform capability (Qt) and minimalist "sorta-GUI" ncurses until the final scalable version of Bitmessage can be taken seriously. You can tweak things and examine the keys.dat effects (easily) and internal stored states in messages.dat (MUCH harder) as new features emerge to real world usage cases and operational issues. Always surprises there. At that point there needs to be some specialisation and division of effort when (say) a definitive API and core is "sealed" as a design. There may be further fundamental protocol - not just implementation changes needed. Quite likely, I'd say. What makes me twitchy is the possibility that valuable Dev time might be wasted on fancy GUI front-ends in the mistaken belief that it would make in more "marketable" and apt to persuade ordinary folk to switch away from email for all personal communication completely. There will be a time for that. But its probably many years from now. Consider the massive stupidity and waste of time that something like MickeySoft Word has caused - by blurring the distinction between presentation document software and simple word-processor. In a UX ans operational sense lets not go down the same road. Otherwise we may be in a situation where ordinary users are unable to make a distinction between when to shift large files by another means and write-off Bitmessage as an email replacement because they cannot. Educating non CS capable users about such issues is every bit as important as producing decent user and introduction media: definitive videos ans documentation for starters. When Bitmessage is at the sealed design stage, or much closer to it. [..] [..]

BM-2cUau5uxBYCK2Z2TVwUZnnNfYW5yyutekC
Aug 11 12:16

As for Java: Java does produce a lot of boilerplate code that makes for somewhat slow development, that's why I switched to Kotlin, which is a dream to work with, at least for a Java developer. On the other hand, the Java platform provides a plethora of libraries and frameworks that makes up for lost development speed. And the argument of execution speed (which you didn't bring up, but always comes up sooner or later) hasn't been true for a long time. Best regards Chris https://mastodon.dissem.ch/@chrigu

[chan] bitmessage
Aug 11 21:34

Point taken. Java does have just about every bell and whistle you could want. And there are many crypto libs ready to roll. Are you saying that development time for large Java projects is somewhat better than say, ten years ago? I remember people complaining about it and all the boilerplate just to do something simple and I assumed it was still the case.

BM-2cUau5uxBYCK2Z2TVwUZnnNfYW5yyutekC
Aug 12 06:39

Slightly better, but not much. For the most part it's Spring Boot which does have way less boilerplate code than Spring from 10 years ago, bit on a language level it's still about the same. But as I said, Kotlin is a Java developers dream. It integrates almost perfectly with Java code, is null-safe and basically has no boilerplate code. Rewriting Jabit was a matter of maybe 10 or 15 hours, without really knowing Kotlin beforehand, and I fixed a few bugs on the way without even noticing. Of course the speed is also thanks to Jetbrains' great conversion tool which is integrated in IntelliJ IDEA. Best regards Chris

[chan] bitmessage
Aug 13 10:45

ice cream, pizza, puppies. Take a breath in......and now out........now go fuck off.

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
Chips without backdoors Aug 18 19:10 4
New warnings in log Aug 17 21:00 20
Yellow peers and green peers Aug 16 20:59 4
cannot import name bmpow Aug 15 12:36 2
Brute forcing BM addr's Aug 15 07:58 4
Bitmessage crashes when posting Aug 14 05:51 10
plz assist. are you a netcat or SSH tunnel guru? Aug 14 05:01 4
shorter bitmessage addresses Aug 14 04:56 14
Why Python? Aug 13 10:45 16
Nerd Bully Aug 13 05:17 1
Bitmessage not connecting Aug 12 04:16 64
Feature idea Aug 10 03:30 10
Local nodes won't connect properly Aug 9 15:51 28
I do any thing in iran for BTC Aug 7 15:36 3
Bitmessage feature request Aug 7 12:50 4
query about short addresses Aug 7 06:54 4
Curious Aug 5 22:39 8
Full time nodes Aug 5 13:50 9
changes to the dodobit server Aug 5 11:05 2
Received Date Aug 5 06:04 13
apinotifypath Aug 4 06:04 9
BM <-> TOR Aug 3 13:19 12
BM Bandwidth Aug 2 14:11 11
When I try to register BM, collided with your key Aug 2 13:51 12
Received Date Aug 1 21:34 4
Bitmessage reminds me of ... Aug 1 14:36 3
I need help Aug 1 13:08 3
Response from Bitmessage Dodo Server Aug 1 02:25 1
Streams and bloom filter Jul 31 21:25 3
Questions about bitmessage streams Jul 31 21:25 1
TTL question Jul 31 08:03 3
API JSON index error Jul 31 07:22 3
API question Jul 30 11:22 7
MiNode Jul 30 07:19 3
Yes it's obvious my BM private keys have been stolen.... Jul 29 19:50 2
Keys.dat options Jul 29 04:56 3
Bitmessage and I2P no longer working Jul 28 22:39 10
Connect Bitmessage only to .onion nodes Jul 27 13:22 3
peers Jul 26 11:36 4
© 2013-2016 The Bitmessage Developers Jul 26 07:12 6
0.6.3 Jul 24 20:52 3
Bug with chan creation Jul 24 10:15 12
Network Size Jul 22 14:47 5