Category: Tech

JavaScript WTFs

I recently did a presentation at work on “surprising” things you may encounter in JavaScript. I present it here for your delectation:

JavaScript WTFs

Sorting arrays was the one that wasted me the most time. Arrays in JavaScript are a neat hack on top of objects. Given that, presumably, all modern implementations have a separate type for an array as opposed to an object, you would hope that at some point they would grow up into something really different in the language.

Goodness in programming languages, part 2 – getting your code running

Posts in this series: Syntax, Deployment, Metaprogramming, Ownership

The fancy word for what I’m talking about here is Deployment. How easy is it, once you’ve written your code, to get it running on someone else’s computer? What barriers are there to someone else using your program?

Examples of potential barriers include:

  • Having to download some other program first, e.g. a runtime or some kind of dependency.
  • The actual program being a huge download.
  • Something mysteriously not working because of different versions of something on the person’s computer.
  • The program simply not working on the operating system or machine architecture of the computer.

Anything that can be done to remove these barriers makes my life as the supporter of the program easier, and makes it more likely people will use it.

Here are some things I like:

  • Java’s ability to run almost anywhere. Once you have the runtime, Java code is relatively easy to get running on many different operating systems and architectures, using almost-identical code. Other runtime-based languages are also strong here.
  • Java and Python’s large built-in libraries. Both Java and Python include large amounts of functionality in their standard libraries, reducing the need to depend on third-party components.
  • Python and Perl’s ability to work out of the box on most Linux systems. If you are developing for Linux, you can pretty much guarantee that an up-to-date runtime will be available, meaning no dependencies at all are needed.
  • Many languages’ easy integration with Linux packaging. Most of the above barriers disappear if you can install dependencies using your operating system’s built-in package manager.
  • Quickly‘s easy way to build your program into the packaging system. Things really become easy if your program itself is integrated into the packaging system.
  • C and C++’s lack of dependencies. It is possible to write C and C++ programs that depend on nothing except standard runtime libraries, which are almost guaranteed to exist on most machines.

One way to handle dependencies is to package them together with your code. This is what most corporate Java software does – the specific Java runtime that is known to work is packaged with the program itself. This makes for big downloads, and defeats the concept of providing a single package for all platforms, but it does work. It also makes for huge headaches to do with licensing, and is often impossible for software producers who don’t employ legions of lawyers. It also feels bad and wrong.

When packaging and deploying software, I subscribe to the philosophy of “Find the dependencies – and eliminate them“. Until someone can click a single button and have your software running, you haven’t finished.

Building jEdit from source

I have recently agreed to take over development of the JSLint plugin for my favourite editor, jEdit.

To start developing I decided to build jEdit and its plugins from source, which wasn’t as easy as I would have expected (thanks to deffbeff for some pointers). A few small changes to the setups for the plugins would make it much easier – at some point I may try to help out there, but for now, here is how I built jEdit and the set of plugins I use regularly:

sudo apt-get install openjdk-6-jdk ant git-core subversion

cd ~/code/public
mkdir jedit
cd jedit

svn co https://jedit.svn.sourceforge.net/svnroot/jedit/jEdit/trunk jEdit

cd jEdit; ant; cd ..

mkdir plugins

Now I made a file inside plugins called build.properties which looked like this:

install.dir       = ../../jEdit/build/settings/jars
jedit.plugins.dir = ../../jEdit/build/settings/jars
jedit.install.dir = ../../jEdit/build
build.support     = ../build-support

And then continued like this:

cd plugins
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/build-support/trunk build-support

svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/ErrorList/trunk ErrorList
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/CommonControls/trunk CommonControls
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/InfoViewer/trunk InfoViewer
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/Console/trunk Console
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/BufferList/trunk BufferList
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/FindFile/trunk FindFile
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/GnuRegexp/trunk GnuRegexp
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/OpenIt/trunk OpenIt
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/RecentBufferSwitcher/trunk RecentBufferSwitcher
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/Sessions/trunk Sessions
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/WhiteSpace/trunk WhiteSpace
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/ScriptEnginePlugin/trunk ScriptEnginePlugin
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/JavascriptScriptEnginePlugin/trunk JavascriptScriptEnginePlugin

git clone git://jedit.git.sourceforge.net/gitroot/jedit/ProjectViewer
git clone git://github.com/andybalaam/jslint-plugin-for-jedit.git jslint

cd ErrorList; ant; cd ..
cd CommonControls; ant; cd ..
cd InfoViewer; ant; cd ..
cd ProjectViewer; ant; cd ..
cd Console; ant; cd ..
cd BufferList; ant; cd ..
cd FindFile; ant; cd ..
cd GnuRegexp; ant; cd ..
cd OpenIt; ant; cd ..
cd RecentBufferSwitcher; ant; cd ..
cd Sessions; ant; cd ..
cd WhiteSpace; ant build; cd ..
cd ScriptEnginePlugin; ant; cd ..
cd JavascriptScriptEnginePlugin; ant; cd ..
cd jslint; ant; cd ..

To find out the dependencies of all plugins and therefore what order to build them, I did this:

find ./ -name "*.props" | xargs grep "depend.*plugin"

Surely something should do this for me automatically?

The problem I haven’t solved yet is that the FTP plugin requires JUnit. I could have copied the junit.jar into the jars dir and I think it would have worked, but I want to do it “properly”…

Finally, I made a .desktop shortcut file in ~/.local/share/applications/jedit.desktop like this:

[Desktop Entry]
Name=jEdit
GenericName=Programmer's Text Editor
Comment=Edit text files
Exec=java -jar /home/andy/code/public/jedit/jEdit/build/jedit.jar -settings=/home/andy/code/public/jedit/jEdit/build/settings %U
Icon=/home/andy/code/public/jedit/jEdit/doc/jedit.png
Terminal=false
Type=Application
Categories=Development;TextEditor;
StartupNotify=true
MimeType=text/plain;
StartupWMClass=org-gjt-sp-jedit-jEdit

Which enabled me to run the jEdit I had built from my system menu.

Note that I am running jEdit under OpenJDK because Sun/Oracle Java is annoying to get hold of at the moment, and generally somewhat evil. Thanks Oracle for killing Java. jEdit does not work brilliantly with OpenJDK, which is frustrating. Maybe I’ll try to fix it?

Goodness in programming languages, part 1 – syntax and layout

In this series I will comment on what I like in some of the languages I use. I will cover things that I find convenient, things that might lead me to write correct code, things that tend to make my code more readable, and possibly other things that I just like for no clearly-articulated reason. The purpose of this series is to help me think about what features I would put in a language if I created my own.

Posts in this series: Syntax, Deployment, Metaprogramming, Ownership

What aspects of syntax and layout – how the code appears in your text editor – do I like? This is entirely irrelevant to the computer that is running the code, and an implementation detail of the language compiler or interpreter, but is extremely important to me.

  • Python and Scheme’s low-symbol approach. Python and Scheme tend towards the use of English words, rather than symbols to express concepts. This makes code easier to read for someone unfamiliar with the language, and also for me.
  • Python’s unambiguous block structure. Python uses indentation to express block structure (e.g. for variable scope, namespaces and logic structures). Programmers in most languages (notably C-like and Lisp-like ones) tend to use indentation to help humans understand the block structure of their code, but the computer uses different symbols to understand the same thing. This can lead to ambiguity where a human may mis-read the real block structure of some code because the indentation is inconsistent with the symbols. Python avoids the problem by making indentation the syntax understood by the compiler. [Go avoids the same problem by stating that code with inconsistent indenting (as defined by the gofmt program) is invalid.]
  • Scheme’s simplicity. Scheme (like other Lisp dialects) has very simple rules to describe its syntax. This means you need to learn very little before you can understand the structure of Scheme programs, and it is unlikely you will be confused by rare structures.

Of course, there are trade-offs in all these points. Using fewer symbols can make programs verbose (although I find Python feels very concise). The lack of an end-of-block symbol makes short Python snippets look clean, but can make longer sections hard to understand (perhaps better editor support would help with this?). Scheme’s use of brackets for everything means there are a lot of brackets, so working out which does what job can be difficult.

Nevertheless, the goals of reducing the number of symbols with special meaning, allowing humans and computers to use the same ways of understanding code, and being as simple as possible are good goals to have.

Ethernet not working on Ubuntu with Realtek RTL8111/8168B

Thanks to rvdavid, the network on my new PC is now working, despite Ubuntu misrecognising it:

How to Get Gigabit Speeds from RTL8111/8168B PCI Express Gigabit Ethernet controller on Ubuntu Linux.

This is the kind of thing I had to do 10 years ago. I thought we’d moved on…