brandonbloom

Just the other day I commented complaining about JSON config files without comments, but now here I am complaining about _three_ ways to write a comment. OK, I can see two ways: block and line comments. But why two ways to write line comments? Why start off a new grammar with that added complexity?

Rather than remove comments, address the primary use case:

https://github.com/edn-format/edn#tagged-elements

I (original commenter) second TOML. It is very simple, is instantly familiar to anyone who has used ini files or many Unix-style config files, and has many good implementations available.

The [[array]] notation mentioned below is a tad weird, but I've never had an occasion to use it.

YAML isn't a particularly good config format either, since it has a lot of unnecessary complexity. For example, bare words are strings, but some bare words, such as "true" are booleans. Which wouldn't be so bad, but did you know that "yes" and "no" are also booleans? I've gotten YAML files from an i18n-system that screwed this up in a pretty bad way.

Apologies for the somewhat off-topic remark, but ... Can we please stop creating new JSON-based config files? Sane config file formats must support comments.

jobu is spot on, but your conclusion doesn't follow.

The truth is that police generally favor body cameras because it protects their officers from an incredibly high volume of false or overblown claims. Here's one reference: https://www.policeone.com/police-products/body-cameras/artic...

And to pile on the point made by the link that jobu posted, Rialto, CA had similarly stunning results in their study: http://www.ci.calistoga.ca.us/home/showdocument?id=18839 - Big drops in both complaints and use of force. London Metro PD too.

Disclaimer/Pitch: I'm a software engineer at Axon, who produces body worn cameras and digital evidence management software. They facilitated all of these studies, since we can't wait around for other people to do it. We're hiring, if you want to work on a product that does some genuine social good. There's some pretty cool problems to work on with the volume of video data we've got, as well as a whole host of other interesting opportunities. You can email me at brandon@evidence.com if you're interested.

Casting one interface type to another involves a dynamic lookup, since you don't know what concrete type you're going to have at runtime. See http://research.swtch.com/interfaces for context.

The name can be arbitrary, as long as it's unambiguous. By the way, here's what mathematica says when I copy paste that and enter x∘y: SmallCircle[x,y]

Also fun:

    In[3]:= SpokenString[x\[SmallCircle]y]
    Out[3]= "SmallCircle of x and y"

Which can be turned in to sound:

    Speak[x\[SmallCircle]y]

Meanwhile:

    Mathematica 10.0 for Mac OS X x86 (64-bit)
    Copyright 1988-2014 Wolfram Research, Inc.

    In[1]:= FullForm[x->y*z^w]

    Out[1]//FullForm= Rule[x, Times[y, Power[z, w]]]

    In[2]:= x\[UnionPlus]y\[RightTee]z

    Out[2]= x ⊎ y ⊢ z

There's no reason your programming language shouldn't be able to tell you what these things are called in English without an external reference.

From second link:

> Obviously on OOM you usually want to abort _something_. It's just not always the entire thread or process.

Surely you want to abort _some dynamic extent_. The fact that it's (currently) a full C thread is an implementation detail that can hopefully be improved. Requiring manual OOM handling on every single operation is not a scalable solution and will lead to bugs due to laziness or fatigue.

Exceptions aren't necessarily bad/evil. A lot has been learned about the challenges of exceptions/conditions/effects. Language designs will evolve to have better versions of what is a foundational idea in the theory of computation.

In the meantime, a try/catch block is only a small macro over thread::spawn, thread::join, thread::catch_panic away. It would be nice if the language supported that without the weight of a full thread.

Presumably, this guy passed the same cookie cutter background check that any employer, including a traditional taxi company, would have used.

+1. I can't say enough good things about Terra.

I self identify as a Lisper (Clojure), but have done a fair amount of professional work in C/C++/Go too. I was productive in Lua/Terra practically overnight. I ported a bunch of Rust (that I had originally ported from C and was considering porting back to C + custom string-templating) to Lua in a few days and the code got shorter, simpler, faster, and with build times of a tiny fraction of those in Rust. Terra just matches how I think about programming low-level code: Types are about shifting work to compile time. Yes, some error-detection work, sure, but that's totally secondary for me as compared to shifting work to compile time for performance, memory representation, etc.

Forgive me, I didn't intend to be so argumentative. I genuinely want to understand. I'm trying to figure out if there are whole categories of use cases that I just don't have any exposure to.

As a side note: I keep trying Rust over and over again, and just can't get in to it. I think my brain just doesn't work that way. For my hobby project that needs super low level perf, I've moved a codebase from C, to Rust, and now to http://terralang.org/ and I'm finally quite satisfied with how the project is going.

We're not going to settle the dynamic vs static debate in this thread, so I'll refrain from commenting on safety and productivity :-)

Anyway, I don't mean to dump on your work. It seems like it's actually quite a nice implementation. I'm just questioning 1) the size of the audience and 2) Whether or not the audience who thinks they want this should actually want this.

Mentioned below where?

If you're talking about query string construction performance, I'm not sure I've ever seen even a Ruby application where query string building was a bottleneck vs the network.

In the context of my original post: 1) garbage collection, which isn't a big deal for most server applications and 2) simplicity, where the complexity of Rust only buys me marginal performance of questionable utility for the sorts of use cases where I'd be talking to a SQL database.

I think that Rust is substantially harder than Go. At least extrapolating from my personal experience and the 6+ highly-skilled people I've watched learn both Go and Scala simultaneously.

+1

It seems like the intersection of good use case for Rust and need to use SQL, will also intersect with "minimal SQL needs", hence preference for simpler libraries.

Hopefully such systems won't be doing a fair amount of dynamic query generation... vs simple pre-baked CRUD operations.

Honest question: When would it ever really make sense to use Rust on the server for a service that interacts with a SQL database heavily enough to justify using such a library?

Wouldn't waiting on the network eat up any possible performance gain you could expect from Rust vs something like the JVM or Go runtime? Before modern day JavaScript JITs, relational database systems were the epitome of dynamic runtime systems. There's so much performance variability in the query planner, network, disk caching, etc, to make garbage collection a rounding error. Zero-cost abstractions are just not a particularly useful thing in this context from what I can tell.

Even if you do have genuinely CPU-bound tasks, why wouldn't you use Rust for those modules + call it via FFI from whatever is doing most of the boring business logic? If it's just about static-type-check-all-the-things! I just can't get excited about it vs something like Go.

There will be no singular panacea for corruption. However, I'd rather put a camera on every officer on their own terms now, rather than pray for them to magically cooperate with some all-or-nothing plan in the future. If nothing else, it will make a strict plan easier to move to later.

     you just can't do police work if you don't have a working camera

This is already becoming the policy in many forward thinking agencies.

    they just need to stream somewhere with associated meta data

There are real challenges, both technical and practical. Technically, you've got to worry about connectivity and battery life. Practically, somebody has to pay for it all! There's also many genuine use cases for turning off cameras during a shift, not the least of which is that officers have to use the bathroom just like the rest of us, but others like when talking to confidential informants or at the request of domestic abuse victims. None of these problems are insurmountable, but it's going to take time, energy, and money.

    I understand it will be hard to get unions to agree to this

That was true a few years ago, but now it's becoming very clear that the majority of decent officers want body cameras. They protect them individually and taxpayers against an endless stream of lawsuits. Google around: studies show that they work, very well, for reducing complaints and use-of-force incidents.

Disclaimer: I work on Axon body cameras in Seattle. If you (or anybody else!) are interested in writing code that will help put a camera and less-leathal weapon on every police officer, please email me: brandon@evidence.com

There's a flag to disable the static linking if you need the dynamism.

That'll do for the hole-filling approach :-)

Awesome article!

Seems a reasonably complete assembler too with one notable exception: Forward jumps, conditionals specifically. These may be a tad tricky to fit in to a monad because they require either knowing the future (eg. how far away the jump target is) or rewriting the past (eg. leave a hole and fill it in later).

I'd really like to see both approaches in Haskell, since they're kinda different. My guess is that in the former case, you'd have nested/delimited monads with buffers. However, I don't know Haskell enough to figure out how to accomplish the hole-filling approach.

EDIT: On second thought, I guess both approaches (traditionally "two-pass" vs "one-pass" assemblers) can be accomplished by changing labels to be opaque rather than addresses and storing a symbol table in either JITMem or the two-types that would replace it for a two-pass approach.

Notably, Go makes a few other decisions that help with this approach:

1) `go fmt` fixes up whitespace, and is fast enough to run on every file-save. Although this sometimes screws up my undo stack.

2) Spaces are still used for alignment, but...

3) Only tabs are used before the content of a line, and...

4) Only spaces are used throughout the content of a line.

The primary reason that I prefer spaces is that it means that I don't have to constantly look at hidden characters while editing. However, go fix's enforcement of the begin/intra-line separation of tabs and spaces alleviates that problem: If it's touching the left margin, it's a tab, otherwise, it's a space.

That's not an apt comparison. This book is about a general technique and problem domain, not a particular constraint programming language/framework/toolchain.

Does it matter? Even if it isn't the latest and greatest, it's still valuable for it's original reason: To teach you about the basics of constraint programming. And now it's valuable for a new reason: To teach you about the context and evolutionary path which led to modern constraint programing.

Often, the latest and greatest is defined in terms of incremental changes from the body of generally accepted knowledge. If you just read the most recent stuff, you'll probably lack the requisite knowledge to understand it. This is true up until the point that the new stuff becomes generally accepted and widely known. At that point, somebody writes it up nice, requiring minimal context, but by that time, it's no longer the latest and greatest!

Yes, to some extent. The workaround is to grown the language towards your problem, which may wind up making a Forth look a lot more like Factor.

Half the reason for Wolfram Language's large standard library is that you should almost never need a third party library of any kind. If there was a third party library that was particularly useful to typical Mathematica use cases, Wolfram would just put it in to the standard library...