A nagging question has held my attention for a week or so now: is there a good high- or medium-level language with a modern enviroment for software development on Linux?
Modern Electric Drill
Let me explain.
In the last few years, I have worked with Objc-C on iOS/OSX, Java on Android and .NET/C# on uSoft. Each of these language environments offers a level above C with garbage collection and a dynamic runtime. The development kits support the easy deployment of code onto devices .. and maybe even a distribution channel like an app store.
On Linux, I have access to C++ and all of the dynamic languages (Python, Ruby, Lua, and many others). C++ is not exactly easy to develop with (for me, at this point at least). Python, Ruby and Lua are great, but have inherited a lot of ideas. The biggest problem with these interpreted languages is that they attempt to target ALL of the operating systems. Python and Ruby distributions are designed to be portable to every version of Linux and also Windows. Python and Ruby programs include features to deal with old versions of the language. What if that was not the case? How much cleaner could they be if their purpose was to produce a single program for a single version of an operating system?
XCode with Obj-C (and now Swift) on iOS set a high bar for what a development environment can look like. It benefits from the fact that the execution target is well-defined and well-managed. There is basically only one target: iOS. I want something like this for Linux. A dynamic language that compiles down to a single executable for Linux. One that is not burdened with support for Windows, or old versions of an interpreter.
Forward your ideas my way.
I like developing using Python. I like its program structure, its performance and the way it supports coroutines. What I don’t like is distributing Python programs. Python installations from one computer to the next are notoriously different from one another. I may have two seemingly similar Linux computers running the same version of Python and a program may run well on one and may not find a dependency on another.
While the language and run-time system is well-defined, they way in which search-paths are set up and resolved does not seem to be. (See http://stackoverflow.com/questions/25715039/python-interplay-between-lib-site-packages-site-py-and-lib-site-py). Virtualenv aims to help, but the contract between Python and “the system” seems not well-defined. The result for me has that it has been difficult to produce shrink-wrapped programs for distribution from Python source.
The types of programs I’ve developed usually have dependencies on locally-developed SWIG-generated shared-libraries (.so), so my case may not be typical. (However, it is interesting :-) I’ve looked at using Cython to compile Python modules, and it works well for building an extension module in C, or for extending a C program with Python.
However, if your aim is software construction using Python for the distribution of a complete application, then Cython seems lacking.
Nuitka (http://nuitka.net) is a “Python Compiler.” Nuitka can compile just one or a few modules, or it can compile an entire Python program. It takes a higher-level view of the job of compiling an entire project.
I’ve shared a little “HOW-TO” article over at Github regarding implementing User-Authentication for a Twisted web-site. The target for this audience is someone who needs Form-based (login page) User-Authentication for a Twisted web-site. It uses Jinja2 for templating. The example shows a recipe for guarding pages, rather than defining an entire authentication framework.
The most relevant “prior art” I had found on this topic was from 2004, and referenced long defunct software components. I thought it was time for someone to do an update.
Apple’s Yosemite has received a lot of attention for the addition of Bluetooth MIDI over Bluetooth LE. What has gotten less attention are the updates to Network Midi. Here are a few things I have learned.
Network Midi has been included in Mac OSX since about 2004. It allows computers to find one another over the LAN via Bonjour and to join each others’ MIDI sessions. The protocol spoken by Network MIDI is defined in a IETF doc: RFC 6295, which was ratified in 2011. An earlier version of this document (RFC 4695) was ratified in 2006. It seems that this protocol standard has had a long and very slow evolution.
Apple’s implementation of Network MIDI has been sometimes criticized as “buggy.” I myself had been able to isolate a bug in the implementation of the protocol. I was delighted to find that Yosemite not only fixes that one specific bug, but seems to include a Network MIDI stack with entirely different characteristics from the previous versions.
- Receive latency is much lower overall.
- An erroneous delta timestamp format has been fixed (comex algorithm).
- Realtime commands are sent (active sense, MTC).
I’ll keep this post updated as I learn more.