t1m

My “first” computer at home was a Burroughs B80. My Dad bought it for his accounting business in the late 70s. It was about the size of two dishwashers, had an 8in floppy, a built in printer and a small flatscreen display (orange on black characters) on a swing arm above the keyboard.

I remember flipping through the B80’s manuals and finding a software section. We could get games for it! I asked dad if we could order some, but unfortunately, he said, the accounting software supplier would void their warrantee if we were to install any other software on the machine.

All of my computer time before buying our Apple ][+ a few years later was spent “playing” data entry on the B80 for Dad’s business.

Back when I was in University, we had an Amdahl mainframe with Unix running under VM. The directory structure included an awful lot of source code. I remember porting source for lex and yacc to my PC-XT running Borland's Turbo C. I assume it was licensed to Universities and source was included under an educational clause, though I'm not exactly sure.

I wonder which version of unix I was using. This would have been around December of '87.

I wrote a language called T for Bell Northern Research, not knowing there was already another T language based on Scheme. The language was used for black box testing testing of terminal interfaces, and so needed good string handling.

One aspect of the language was that Unix regular expressions were a built-in type, and so were associate arrays. These two features worked together in a cool way:

  x['hi there'] = 5
  x['hello'] = 2

  # regular expressions are enclosed in `backquotes`
  x[`hell.`] == [2]
  x[`h.*`] == [5, 2]

We used this incredibly fast/compact library for Hustle DB indexes. Anyone needing a good Python interface to it could pry it out of the dependencies: https://github.com/tspurway/hustle/tree/master/deps/libebset

I am a Canadian, so I neither have a say, or really can comment on American politics.

This Saturday, my two daughters (ages 11 and 8) are driving a 1,700km journey to North Dakota to show our support for the #NoDAPL movement. I am doing it because my eldest is really into Aboriginal rights right now. These people are just trying to preserve their land.

I hope we don't get shot by Peter Thiel.

Tens of millions of people are going out to the street and are not going to let these little goons take over America.

Peter Thiel's "Mein Kampf" excludes women and minorities, who he feels have "damaged" democracy: https://www.cato-unbound.org/2009/04/13/peter-thiel/educatio...

https://www.cato-unbound.org/2009/04/13/peter-thiel/educatio...

Thiel believes that women and minorities have damaged democracy and openly questions whether they should be allowed to vote.

I am reeling.

Leonard's music had an uncanny sense of timing, both musical and cultural. He referenced the external, political world, indirectly - not through selfishly inward bullshit, like many of his contemporaries, but by sifting it through relationships with others and his relationship to the divine.

As I am writing this, the next article in hackernews is about Peter Thiel and his ascension to whatever office he is seeking in Trump's cabinet. His views on the damage women and minorities have done to Libertarianism (whatever that is), and how democracy is shit are well known, and I will let you judge how Palantir has benefited humanity.

The thing that gets me is his straight faced desire for immortality. Note that he doesn't wish for immortality for someone who is great, he wishes it for himself.

RIP Leonard. You already are immortal.

Prefix notation (ie. + 1 1) instead of infix notation (ie. 1 + 1) is much easier parse, as there are no precedence rules and you don't require different conventions for expressions and function calls.

The wise programmer is told about Tao and follows it. The average programmer is told about Tao and searches for it. The foolish programmer is told about Tao and laughs at it.

My interests in C, compilers, small computers and Unix at the time wasn't driven by career aspirations. I was just genuinely interested those things. Maybe I was "unemployable".

I remember showing my "systems analyst" brother-in-law my second year university schedule when I was planning which courses I would take that fall.

"You don't have any Cobol, PL/1, OS360 Assembly Language or APL on here", he observed.

"I am going to focus on C, Unix and operating systems. I want to write compilers for microprocessor based computers".

When he finished laughing, he called me "unemployable" and said, "microprocessors will never be used for anything but toys. Take COBOL!"

Since then, I have made a point of not even looking at COBOL code. I have been in the presence of COBOL, but have averted my eyes.

I am an anglo who speaks french (like an anglo) and don't think I have amused my Quebecois friends more than when I used 'tabernouche' in a conversation.

It's a bit of a pro-tip for anglos - you can sound a bit crass going full-on tabernak calise etc., but droping the 'tabernouche' with anglo accent wins every time.

Mozilla | Senior Software Engineer - Content Services | REMOTE | @t1m

Some things we are working on:

* our new Firefox `about:newtab` page - (JS, Service Worker API)

* data engineering at scale (Python, stream processing, various dbs, data visualization)

* Content Management web applications (Python APIs, JS/React front-end)

* privacy research, privacy engineering, privacy protection

* user personalization research and engineering

Our mission is to advance the end-user's interests in an increasingly adtech dominated web. We have positions open for adventurous engineers with demonstrable skills and experience.

It is true that one of the motivations is to diversify our revenue stream; almost all of our revenue comes from our Search (advertising) deal with Yahoo.

The real reason we are doing it is because modern digital advertising sucks, and we are going to change how it works.

The current ad-tech 'environment' invades your privacy, robs publishers, and delivers deplorable performance for the brand. The only winner right now is the middle-men; the 'programmatic' exchanges and the various money siphons that trade your personal data.

We want to fix that. We are starting by building an ad targeting mechanism in the browser that you can easily control and that doesn't leak your data. Currently, ads will be shown only on the Newtab page, though one could imagine a generalized future version of this capability opened up to all internet publishers.

We designed Suggested Tiles to respect user privacy. Instead of centrally collecting as much data about as many people as possible (the strategy of all other ad-tech companies), we distribute all possible ads to all users and let Firefox decide what to show. This prevents your data "leaking", while showing you relevant advertising that you can control.

The user interface is designed to help you understand why you are seeing the ad, and to allow you to easily and permanently disable this type of advertising from your experience.

Our goal is to provide effective, relevant advertising without sacrificing user privacy.

For those interested in the transparency of this, all of the server-side software for this is on github:

https://github.com/mozilla/splice https://github.com/mozilla/onyx https://github.com/mozilla/infernyx

And tracked openly on Bugzilla:

https://bugzilla.mozilla.org/buglist.cgi?product=Content%20S...

You may have failed, Wattage, but you certainly left the place in better shape than you found it!

In a time where a good portion of the industry is helping us click on ads that we would rather not see, you attempted something difficult, different, and with less money than most VC backed start-ups spend on their espresso machine.

I am looking forward to your next venture.

Note that intersections using HLLs don't work in general. The error rates become gigantic for sets that have small intersections, or whose cardinality differs greatly.

A general solution to cardinality estimations for intersections is to just use HLLs for union operations, and keep a MinHash sketch for each key as well to perform intersections.

There is a very good analysis of this technique over at http://tech.adroll.com/blog/data/2013/07/10/hll-minhash.html

Smalltalk-80 used the underscore '_' character for assignment. It was also rendered as a left pointing arrow.

I think Aerospike has a very similar featureset. It is ACID + NoSQL, replicates nicely across multiple data centers, and definitely has a similar/better latency and throughput profile than FoundationDB.

The US should follow Canada's lead and not tax exercised options until the stock is sold and actually becomes income.

http://www.taxplanningguide.ca/tax-planning-guide/section-1-...

Byte Magazine had a history of forward-looking articles for microprocessor and software technology. There were entire issues devoted to LISP in (1979), Smalltalk (1981), and the 68000 (1986). It wasn't that C was new, it wasn't, but in 1984 it was certainly new to their target audience, which was the micro-computer industry.

While it's true that C compilers were available for MS-DOS and CP/M in '84, these were by no means mainstream, and were prohibitively expensive. Turbo Pascal was still taking the world by storm, and it would be another three years before Borland would introduce an 'ANSI Compatible' C compiler and IDE - the much anticipated (by me anyway) Turbo C in 1987.

You can combine perfect hashing with string compression (Huffman, prefix tries) and de-duplication techniques to vastly improve memory usage for a wide variety of use cases. DiscoDB does this to good effect (http://discodb.readthedocs.org/en/latest/).

This is not surprising. My grade 4 kid's teacher told me that our kid "just might not be good at math, and that's OK". This is a shocking attitude, but one I find commonly held: that basic math is some kind of optional, specialized skill.

I am going to suggest that 'Structure Packing' isn't the lost art. I think the lost art is 'Variable Sized Structs', the emphasis on the last 's' of 'Structs'.

This is the situation where your solution calls for an array of structs that are contiguous in memory but aren't the same size. This happens oftenish in database, os, and compression tech. C99 and gcc have legalized the often used convention:

  struct varb {
      char *foo;
      unsigned char age;
      int number_of_bars;
      char var[];  // it's something like var[0] in GCC, or var[1] in versions < c99
  };
   

- the variable part must be declared last

- the struct may not appear in other structs or arrays

which totally makes sense, but doesn't help us implement a contiguous array of variable length structs. Also, the restriction of having the variable part of the struct come last may waste a lot of space if we have a structure where we would rather optimize the order of the struct ourselves, but that's another post!

Assume we are OK with the limitations of our struct varb, we now need to declare and malloc (or mmap) a char* (to hold all of our data) and lay out our varb structs fairly manually. Once we have found the start of a particular varb struct, we can cast it's char* address to a struct varb* and the compiler then can help us populate or interrogate our data. Note that we will need to keep track of detailed memory usage 'so far' when we are populating as well track padding, alignment of adjacent structs, as well as any reallocation when our struct array needs to grow.

So if you have fixed sized 'ziplists', why don't you do a memmove() instead of a realloc() on inserts, then split your array on overflow? That would be 1 malloc per 1024 inserts assuming 8 byte data in an 8K page instead of 1 malloc per insert.

This would be vastly more cache friendly, and you would be fragmenting your heap dramatically slower. You could even mmap() a scheme like this, but that's another story!

My code above isn't the exact syntax. I doubt I implemented array equality. I was just demonstrating that an array would be returned when indexing the dict with a regexp.

I know nothing was published or released. I actually left BNR/NT less than a year after the language went into production (going to say July, 1990) - I don't really know how long it remained there. Perl was popular, and Tcl was definitely a 'thing' in the lab at the time - the writing was on the wall for home-grown languages.

I have wondered the same thing, but wasn't extremely concerned about getting it super-fast at the time. We had an existing, older language that was much loathed and quite slow, and we just had to beat it. And awk.

I was hired (a long time ago) to write a language for a Very Large Telco Equipment Supplier in Canada in order to support their automated regression testing effort for their digital telephone switches.

It was called, ingeniously enough, "T" (no, not that "T"). As far as I (and cursory Google searches) know, it was never released to the adoring public.

I used lex and yacc (half jokingly referred to as 'ick' and 'yuck') and K&R C for the compiler and VM.

The particular type of testing we were targeting involved writing test cases that would read/write over serial lines to a telephone switch's console program. Therefore, the language needed to have good serial/terminal I/O, and it needed to have amazing string/pattern matching.

I wrote two features that I am still particularly fond of:

- regexps were a built in type. Strings were written like 'hi there' and regexps were written like `hi ..ere` - supported standard unix regexps

- associative arrays. Lots of languages have these now, like python's dict

The cool thing about it was how we tried to allow strings and regexps have a polymorphic relationship at the language level. The statements:

  x == 'some string' or x == `some [^t]ring`

  dict['hello'] = 4
  dict['help'] = 2

  dict[`he.*`] == [2, 4]   # true