Tag programming

The Coding Robot

Back in 2019, after deciding to leave Beat, I was contemplating starting a new project. It was an ML-based project, informed by my experience at both smaller and larger companies, like Beat: An ML-based Code Reviewer. The idea was that smaller companies, founders aside, seldom have senior engineering talent on board, and the quality of […]

Go and Javascript.

I’m going to go out on a limb and predict that Python is being replaced by Go. I don’t have a lot of information to back up this prediction except that most of the positive articles I read about Go are written by Python developers, and a lot of them say that they are now actively migrating their code base from Python to Go. I don’t see as much enthusiasm for Go from developers using statically typed languages, probably because of Go’s antiquated type system (which is still a big step up from Python, obviously).

Codify for iPad

I've been a fan of Lua since the early 2000s when a friend introduced it to me, even though I never got around to finding the time to properly learn and use it in production stuff. We have discussed about using Lua as a scripting language to allow for downloadable bundles that would extend AthensBook/ThessBook functionality (or fix bugs, or provide dynamically determined personalised features etc., but that never happened until now, due to licensing restrictions by Apple) for ages. Codify is an unbelievably cool app that leverages lua to provide a simple programming environment for the iPad. Combined with the general appeal of the device, the lack of third party, scripting programming environments for it, the ease of programming and use of Codify and the excitement of using such great hardware, I feel that Codify might be the Logo/Basic equivalent for this generation of children between the ages of 5-10, a great introductory platform for programming and an amazing tool for everyone else. And at $7.99 I think it's a steal. You might want to use a bluetooth keyboard for it though; typing code on the on-screen keyboard seems like a horrible horrible nuisance.

Rails3 Critique Tidbit: html_safe, raw() and h.

One of the most annoying thing with Rails has always been how it provides for convenience at the expense of uncertain (and sometimes shady) abstraction implementations. It's a great framework for prototyping, yet there are reasons why quite a few people are skeptical about it. Nevertheless, in the truest tradition of Ruby, Rails provides a pretty clean way to do web application development. Rails 3, the latest incarnation of the framework builds upon a solid foundation, offering great improvements in many areas. But not everywhere. Take for example the html_safe string escaping that supersedes 'h'. In Rails 3, all input strings are automatically escaped, unless the developer passes the string through raw() before the string. That's fine, as it's bound to make sloppy developers safer by forcing them to go out of their way to leave the string unescaped. One of the issues with this, however, is how the old way of escaping, 'h', is still around in some cases: say when you want to render a link using link_to and you use raw to provide formatting to your link (via span) and include some part of user provided input (as found in the example provided in the xss and scripting screencast at 02:20), then you have to resort --- once again --- to using 'h'. This is confusing and inconsistent; if all strings are automatically escaped, you'd expect input variables to be automatically escaped too, even if included in strings using raw().