Saturday, May 26, 2018

Please do not break my code

How long should code last?
I started coding in Java back in the last millennium.  I fully expect that code I wrote back then will still work on a modern JVM, indeed some it may still be running today.  It would probably run faster and better than it did when it was first written given the improvements in hardware, JIT optimizations and garbage collection.

For the last year or so I have been writing in Python ... Python 2 to be precise.  I have no hope that in 20 years any of the code I am writing today will be runnable yet alone running.  Python 3.0 was released December 3, 2008 ... almost a decade ago.  Why am I using Python 2 in 2018?

If we look at Python Versions Used in Commercial Projects in 2017 we see that I am not alone.  63.7% of commercial Python projects are still using 2.7.   If Python 3 is better (which it is) why are so many projects still not using it after so many years?

To deprecate or to break

Often language designers and library maintainers are faced with a difficult decision of deprecating code or introducing breaking changes.  There are large costs to either decision.

Back in 1996 Java introduced the deprecated tag as a way to mark code as:
  • the old API is insecure, buggy, or highly inefficient
  • the old API is going away in a future release
  • the old API encourages very bad coding practices
Fortunately, the second reason for deprecating was never really implemented.  Nothing deprecated has ever been removed from the language.  Nothing.  

Whoever made the decision to not remove deprecated code should be given a Nobel prize.

This decision means the burden of the deprecated code remains with the owner of the code.  Each release will need to test and validate code they would rather not have to maintain.  This is no small cost I am sure.

Compare this with the Python decision to make breaking changes moving from Python 2 to Python 3.  By making this decision, they try to move the on-going cost maintaining "dead" code to a one-time cost distributed across all projects using Python.  

The cost for just one company (the one I work for) to move to Python 3 will be enormous.  Because there are known breaking changes, all code will need to be treated as unreliable and have to be proven to be working correctly.  This is not just code we have written but any library we have included as well.  This represents hundreds or thousands of man-hours and increased risk ... ALL FOR NO BENEFIT.  If all goes well after weeks or months of effort, we will end up with the exact same functionality we started with.  Or, we could focus on what keeps us in business.  Hence the reason we are still using Python 2

Which means that the effort to distribute the cost of the breaking changes to everyone else has not really worked out.  2/3 of projects are still using the old code after 10 years.  The one time cost has becoming an on-going problem with no end in sight.  There are no winners in this debacle, just a fractured community.

Don't get me wrong, I like Python.  It is unfortunate that this difficult decision resulted in a situation that detracts from the usefulness of the language.

How long should code last?  As long as it is useful, not just until some language or library owner decides it is better to break it.  Please do not break my code.

Tuesday, November 8, 2016

lein-resource 16.11.1 released

New resources
lein-resource is a  plugin that can be used to copy files from mulitple source directories to a target directory while maintaining the subdirecotries. Also, each file will by default be transformed using stencil.

Version 16.11.1 
gh-22 - adds support for the the case where you want to render the templates with different variables based on the target path, to allow using some view-logic say, for a dev and prod output.
As in #1, but allowing for :extra-values to be passed with each path:
  :resource {:resource-paths [["resources"
                               {:target-path "app/dev"
                                :extra-values {:dev true :prod false}}]
                               {:target-path "app/prod"
                                :extra-values {:dev false :prod true}}]]}

Sunday, August 30, 2015

Using the Windows Vista recover partition to install to a new hard drive

Alas, the hard drive died and Windows vista no longer boots.  How to get it installed on a new hard drive using only the recover partition from the old one.

  1. Attach a USB drive with at least enough free space to hold the recover partition.
  2. Boot using puppy linux
  3. Mount the USB drive (assuming sdc1 and also assuming the recover partition is sda2
  4. Create a directory called recover on the usb drive
  5. Copy the partition using dd: dd if=/dev/sda2 | gzip -c | split -b 2000m - /mnt/sdc1/recover/recover.img.
  6. Turn off the computer
  7. Replace the old hard drive with the new one
  8. Boot again
  9. Using Gparted (System -> GParted Partition Manager)
    1. Create 2 partitions
    2. Make them both ntfs
    3. Use manage flags to mark the second one 'boot'
  10. Copy the partition" cat /mnt/sdc1/recover/recover.img* | gzip -dc | dd of=/dev/sda2
  11. Mount the sda2 drive
  12. Run ntfsfix /dev/sda2
  13. Run Grub4Dos