First.io | Back-End Engineer | Rails/Postgres | Durham NC or Remote | Full-time

First is a venture-funded startup at the intersection of artificial intelligence and real estate tech. We identify when people are going to move, and develop products to change the game for real estate professionals.

* 5+ years of developing Rails applications in production

* SQL and relational database experience (not just using a database through an ORM; Postgres a plus)

* Experience in building APIs (REST at least, GraphQL a plus)

* Generalist mindset, excited to jump into many parts of the stack to ship working software

* Clear, effective communication skills, both written and verbal

* Experience with agile practices, including TDD/BDD, continuous delivery, object oriented design, etc Comfort with asynchronous development: pull requests, chat, email, etc

* DevOps and AWS skills a plus

Read full job description and apply at https://boards.greenhouse.io/first/jobs/1562700

First.io | Back-End Engineer | Rails/Postgres | Durham NC or Remote | Full-time

First is a venture-funded startup at the intersection of artificial intelligence and real estate tech. We identify when people are going to move, and develop products to change the game for real estate professionals.

* 5+ years of developing Rails applications in production

* SQL and relational database experience (not just using a database through an ORM; Postgres a plus)

* Experience in building APIs (REST at least, GraphQL a plus)

* Generalist mindset, excited to jump into many parts of the stack to ship working software

* Clear, effective communication skills, both written and verbal

* Experience with agile practices, including TDD/BDD, continuous delivery, object oriented design, etc Comfort with asynchronous development: pull requests, chat, email, etc

* DevOps and AWS skills a plus

Read full job description and apply at https://boards.greenhouse.io/first/jobs/1562700

The point about partial programs is a particularly strong one, especially when it comes to test-driven development. Being able to write a test for a method or function before that method or function even exists may seem like a small thing, or even pointless ... but that flow and rhythm of "write the test, make it pass, refactor" is so strong and natural (once you've grown accustomed to it) that having to break that flow for brand new methods feels quite disruptive.

It's pretty easy to add typed holes to a statically typed language in many cases, which will simply cause the program to panic if they end up being instantiated. I'm not really sure what issue the author takes with inserting panics / bottom until you're ready to actually deal with the problematic cases--the only way to make it more ergonomic would be to make it the default behavior, which pretty much means you're not getting any benefits out of type checking.

I thought that was a pretty weak point. Rust has `unimplemented!()` and Scala has `???` which can be put anywhere to make the program compile.

Ah, good to know. But at the time, they were mostly valid criticisms.

I'm pretty sure that was Chris Morris. (He and I were both regulars at that group.)

Hi Glenn :-)

I could have sworn it was a _different_ Chris. I remember someone with black hair. He may not have frequented the meeting as much, because I don't remember seeing him again after that.

(P.S. I've updated my profile.)

Ah, OK. (And yes, I remember you. You ran the FW JUG for a while?)

Yes, that was me.

There was a semi-rebuttal … I think in a post from Brent Welch. Tcl does have things called "arrays", and you use them much as you'd expect. Tom Lord confirmed later that what he and RMS meant by this was that it didn't have "true arrays" that are laid out contiguously in memory, to be much more efficient. That's a valid criticism: Tcl's arrays are basically dual-use hash tables, much the same as JavaScript's arrays.

The other two things are totally valid. Tcl has no references, so you can't build your own linked list. And all values are (at least semantically) strings, so numeric operations are slow.

But of course, a lot can be done to optimize those things in the implementation, and over time at least some of that optimization was done.

> all values are (at least semantically) strings, so numeric operations are slow.

All values are _still_ semantically strings (it's a core tenet of Tcl: "Everything is a string (EIAS)"), and in 1994, they were practically strings, too (that was the implementation). In 1999 w/ Tcl 8.0, Tcl became byte-compiled and adopted "Tcl_Obj" to represent values[0]. The Tcl_Obj (nothing to do w/ object-oriented programming), is what's called a "dual ported" object. It contains a string-representation of it's value (to preserve EIAS), and a "native" value of it's last computed use. For example, if you:

  % set a 9.0
  % expr { $a * 0.01 }

The native value of the Tcl_Obj $a refers to will be a float. Repeated calls to $a in a float-context will continue to use this already-computed native value. No need for further string interpolation.

[0] http://www.tcl.tk/software/tcltk/8.0.tml

[edit: formatting]

Lists are a first-class object in Tcl, so it's not clear to me how much of a deficiency not having linked lists is.

I've had cases where opening a 'C' program as a pipe and doing heavy number crunching in the 'C' program outperformed native Tcl.

Well, right. Tcl was an early example of a trend where key data structures were built into languages and fairly well encapsulated as "one size fits all" abstractions. Computers had become fast enough that for many purposes you didn't have to build a custom list or hash table.

That all seems normal to us now, but it was uncommon back then.

> Lists are a first-class object in Tcl

Was that the case in 1994, or are you writing about the current state of Tcl?

I believe it's been true since the language first saw light.

I didn't get to it until around v7.x around 1995 and lists feature prominently in Osterhout's book.

Two things about it make me think that RMS actually wrote it (probably after consultation with Lord). The first is this sentence in that post by Lord: "Who cares if a post occurs under my name that I didn't post so long as I more or less agree with it -- this isn't about ego."

The second is writing style. The Tcl War post is classic RMS. Compare it to this reminiscence from Lord and it's hard to imagine they were written by the same person.

When I wrote my comment above I skimmed through Thomas Lord's essay, found that the parts I remembered being there were all in their place, pasted the link and pressed "submit". In particular, I remembered the paragraph from which you quote as written in a ironic manner, suggesting with a wink at the reader that Lord actually wrote the post. Now that I've reread the essay, I don't see that at all. I think in that paragraph he probably says what he means. That, and you are right about the style.

In short, I retract my claim. Sorry to whoever I misled! My confidence was completely misplaced.

I should be wary of the account anyhow. For calibration: it's just false to say egcs was due to "friends of Cygnus" and "hostile"; it was friends of GCC with the intention it should turn out as it did, happily.

I can't find anything archived to check but, as I recall, Lord later posted a bizarre sort of semi-retraction in rms' name, and rms fired him soon afterwards, possibly as a result. Perhaps that's partly a source of rms-didn't-write-it ideas? I don't remember the suggestion at the time.

Heh. In a recent overhaul of my site, I considered taking these pages down. But they do still get a reasonable amount of traffic, and I hate broken links.

Thanks to amelius for the "Tcl the Misunderstood" link. I agree with that, for the most part. I haven't written Tcl in many years, but I don't think it deserves the reputation that it has.

It did later come out that Tom Lord wrote it, but not as a prank; he was working with RMS to build Guile, and this was the opening salvo in trying to build the case for it. RMS did post it under his own name.