Martin חיים Berlove
creator, thinker, polymath
Selected Projects / Achievements / Activities
Calm Speech Project[In Progress]
Goal: Achieve a better society through better communication.
A short guide to help people learn new tools and frameworks with less hassle
Received Mongo DB developer association
Customized Vi[m] themes
Much to my surprise, I've become something of a vim adherent, enough to want my own themes to suit my preferences.
Simple Trello tasklist integration using PHP
A small task list app made using Ruby's Hanami framework
Decided to kill two birds with one stone and make a productivity app for myself while learning a newer framework.
A better way to think about the money you spend
Conceptual game made for Github Game Off 2016
Extensible interface for demonstrating graph theory fundamentals.
Pong clone in JQM that supports touch.
Video-based classes on various topics in computing
A variety of raytraces for fun and education
Learning German language, spoken and written
Through the use of Duolingo, textbooks, online tutoring, and immersion, I hope to bring my skills up to a level for day to day communication with native speakers and to read technical papers written in German.
Explorations in music creation
Summary of Experience
Recent Writing (@MartinBerlove)
Tips for Using ‘ed’ (the Text Editor)

The question of “why bother using ed?” demands an answer, but I opt to defer that answer — it’s a worthy discussion on its own.

Ed has a limited featureset and only a few commands to memorize, but using those commands efficiently can be confusing. Following are a few methods I’ve picked up for making the best use of my keystrokes.

Let’s say I have a line of code like the following:

var item = Data.create();

I don’t like the vagueness of the term item so I want to replace it.

I could find out the line number and change it, which would look something like this:

var dataItem = Data.create();

And then I check my work in context: 145,150p.

But I could also perform a substitution given the line number of the search in one step, like this:


Then I still might want to check my work, requiring another line. I can consolidate that further in one line, like this:


With the p at the end of the line running a print on the line number on which I operated.

Depending on the term in your regex, you might not be sure you’re hitting the right line. You could always make the expression itself more specific, or instead, you could check your place in the document.

For instance if you do a search and want to know where it turns up, try this:


You could always print the section around the text:

27 ...
28 ...
29 ...
30 var item = ...
31 ...

32 ...
33 ...

Repeating this sort of navigation pattern does “break” the purpose of ed just a bit after all, but that doesn’t mean it’s a poor workflow.

If you know where you are roughly, you can use a line number:

var item = ...

Just make sure you don’t reference a line number that comes before the searched line, or you’ll confuse ed. You can always check with .=.

If you’ve marked your line with k, you have it easy, but let’s say you don’t know where you are at all contextually. In such a case, you can use a relative address:

var item = ...

Or even another search term:


Bear in mind that these all rely on the internal reckoning of the address. Running a search command will change the line you’re on, so pay attention to the sequence of commands you run!

For instance, if you run a .,+5n you’ll get something like this:

38 current line!
39 ...
40 ...
41 ...
42 ...
43 ...

However .= will now tell you that you’re at line 43. Ed can be confusing, but it sure helps you focus.

Another intriguing if slightly hacky way to navigate is by injecting unix search commands:

!grep -n 1 item file

Or even:

!less file

Search what you want, then discard the rest, and you’re right back in your editor. Of course, to a purist, this feels very wrong.

One other nifty way of easing the editing process uses a combination of w- d-r. Personally I find this useful if I have lots of different ideas and bits of text to keep track of.

Here’s how: Save some lines out into a file, delete them from the buffer, and ignore them until you need them later at which point you can move your address to the location of interest and read them back in using r.

If you just have one piece of text to move and you know where it goes, you can use m to move the lines, but there are a lot of cases in which you have snippets of text you want to hang on to — and writing the buffer to temp files works great for this situation. You can always delete them right from within ed using an injection like !rm ./tmp* without ever leaving your ed session.

Through a combination of regular expressions, line addressing, command injection, and the occasional manual edit, cruising your way around a file (or files) in ed can be a breeze.

(I still haven’t addressed the why. That’s for another time).

⇣ expand ⇣⇡ collapse ⇡
The Utility of Tinkering

Last week I spent several hours building a chatbot mechanism from scratch, being inspired by some article or another to try to better grasp the concepts of text comprehension.

After much struggle, and several frustrating reformulations which required retraining the thing from scratch, I finally got it working…and it output nonsense.

Several versions and hours later, it reached its peak, achieving the laudable ability to spit out semi-coherent sentences which, if you really thought about them, tied in to the subject matter at hand.

So then I made a new bot and used a tried-and-true, if basic, rendition of a Markov chain generator. In the span of about an hour, I had results that at least equalled and possibly surpassed my original model.

It was frustrating, but also pretty awesome.

Then I asked myself the question: was building that first model even worth it?

And, as that was obviously a leading question, the answer is a resounding “yes.”

But of course, that reaction is just a gut instinct. If you pressed me for details, I’d give you a few of my stock answers for why I think such ventures are worthwhile, even if I never touch that code again:

  • Building the first model helped me understand the concepts better
  • Having two models to compare gave me insight into what works and what doesn’t
  • I have greater respect for what it takes to build an advanced interactive system
  • I can now add this kind of code to my repertoire in a way that I could not had I just built the second model

But truth be told, while those all may be legitimate reasons, they are also, frankly, excuses. Because the final and perhaps most relevant item on that list should should be as follows:

  • I like playing around with things

The tinkerer’s mentality is a large part of what got me into software development and technology as a whole in the first place, and it remains where the majority of fun remains.

And though I cannot give you concrete proof of this, I firmly believe that “tinkering” is important, not just as an individual in terms of learning, exploring, building your skills, but also for society. Tinkering is an investigatory process without a goal and therefore without restrictions; it is creating something elevated out of the mundane: pure human curiosity being used to expand the bounds of our collective knowledge and abilities.

Call me a dreamer; I won’t be too insulted.

⇣ expand ⇣⇡ collapse ⇡
Mathematics, and Pertinence to Software

Programming is often viewed in a vacuum, as the tool that makes software do what it does. This is often true both on the part of those who learn programming to get a job, and for those who employ programmers as code jockeys to “make things work.”

When this view becomes too limiting, the broad-minded approach usually next encapsulates programming’s pertinence to the business as a whole, viewing software use as an integral part of the business process.

What usually gets left in the dust are the mathematical formulations behind software, typically viewed as highly theoretical and inappropriate or unnecessary in the business context.

For some very limited contexts, this may be true. If you have extremely limited manpower, if the focus of your business is small and directed, and will remain small and directed for the foreseeable future, and has absolutely nothing to do with any kind of math, or lies in such a completely understood field that no new techniques could possibly be developed, then there may be a valid reason to ignore mathematics.

Outside of such contexts, mathematical comprehension drives success in both the short and long term.

Financials, data analysis, artificial intelligence, computer graphics and visualizations, business development, business efficiency, hardware research, materials science, mechanical engineering, transportation and the supply chain, robotics, libraries, education, medicine, language work, governing, fundraising — all these areas use software (or should use software) which is bettered by the knowledge of mathematics, can be improved by mathematics, and for which a solid understanding of mathematics will allow yet more advanced software to be developed which will advance the given field.

With that little rant out of the way, let’s take a far from comprehensive look at a few common areas of mathematics and how they pertain to software.

Discrete Mathematics

This one’s fundamental. If you want to build an algorithm, or even understand the data structures used in just about any software system, you’ll need discrete math. If you touch no other mathematics beyond algebra, this would be the one you want. Without discrete mathematics, modern software falls apart.


Ah, calculus. The big bad slog that some people understand intuitively and others crunch away at formula by formula for years. Why does software need calculus?

At its most basic, it doesn’t. Software hasn’t run on differentials since mechanical computing, and many a “software professional” goes to market with at best a hazy concept of continuous functions.

Yet look around, and you see calculus everywhere, driving everything. It’s in . And maybe most importantly, a strong understanding of the principles found in and derived from calculus are requisite for other, more directly applicable areas of mathematics such as probability, differential equations, and combinatorics.

Differential Equations

This is a huge topic, and some of it is so esoteric that only engineers in very highly specialized fields or scientists dabbling in the mysteries of the universe will touch them with any frequency. But others are more common, useful to many trades including software. In particular, linear differential equations is used in analyzing large data sets, calculating computer graphics, teaching AI, and so much more.


Combinatorics broad arena of mathematics, with a broad range of applications. Different courses of study will touch different topics here, but at its core deals with the counting and countability of certain types of structures. Understanding this subject requires a certain understanding of discrete math, general mathematical thinking skills, and potentially a few other topics, but is not necessarily “hard” the way other fields may be perceived to be.

Learning the various skills here pairs well with just about any other mathematical discipline that has ties to computing.

Graph Theory

Though often taught as its own subject (and for good reason — there’s a lot to learn), graph theory is really just a highly refined subset of discrete mathematics and algorithm studies. A graph in the world of computing is a discrete structure of connecting nodes, and is used to store connected information. Graphs are of particular interest as they possess many subtle and surprising properties that make themselves known only after significant study, yet yield themselves to typically very efficient algorithms used to gather and process information.

Graphs are pertinent to many areas of computing, including databases, machine learning, and interconnectivity (both human and artificial). For instance, a graph might be used to track the connection between to people on a social network, the location of a phone within a cell network, or the number of citations a paper has received.


Some might consider this an “applied” math, since its principles lie in a few different disciplines, but cryptography is a hot topic in math and is often taught as its own subject. Prime numbers are the big winner here, and they and a handful of other basic mathematical tools are employed to perform impressive feats of encryption, verification, and protection.

Cryptography typically requires putting one’s nose to the grindstone, but the benefits are enormous, especially in terms of monetary losses offset when data breaches or hacking attempts are avoided. Remember, for every awful data leak you hear about, there are a dozen failed attempts thwarted ahead of time by the ongoing efforts of people working in cryptography and related fields of study.

Probability and Statistics

Some might consider this pair of items to be one, but either way they form a kind of holy grail of computing, permeating almost every single topic of computing. Every topic in math feeds into it, and it in turn feeds every topic. Financial analysis, biometrics, data processing, artificial intelligence — so many fields rely directly on an astute understanding of probstat.

Look no further than the nearest rookie plying a natural language processing algorithm he doesn’t understand in an attempt to build the next big-selling chatbot, and you’ll quickly see the ramifications of ignorance in this area.

You don’t need to be an expert here to make good use of such skills. A strong comprehension of the basic principles and common formulas (and what they mean) goes very far, and forms a basis for building new skills on top of it.

Software relies on probability and statistics to “make things work.” Or rather, software relies on programmers who understand how probability and statistics work.

⇣ expand ⇣⇡ collapse ⇡
Recent Tweets (@MartinBerlove)