Static types in Python - <AUTHOR> http://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/ <comment><USER4> I just tried taking the article's advice, and running mypy on some of my code (completely unannotated) to see what came up. Some interesting things have, already made 3 patches.

One comment to the article author: Tell people how to install mypy. I started by trying 'pip install mypy', then wondered why I didn't end up with a mypy executable (you need pip3 install mypy-lang, mypy is an unrelated package).

<comment><AUTHOR> Thanks for pointing that out, fixed!

</comment></comment><comment><USER5> Honestly I haven't looked into MyPy a huge amount, and haven't used it yet. But from reading the docs on it I feel like it's taking the wrong approach. In my opinion, Python is all about duck typing, so having a static type checker that seems to focus on concrete types feels wrong to me.

Consider the first example,

      def sum_and_stringify(nums: List[int]) -> str:
          return str(sum(nums))

The type here is way more specific than it needs to be. Not only will this work on any sequence type (anything that supports __iter__), the element type only needs to support __add__ and __radd__ (to work against the implicit seed value of sum).

I really feel like in order to get the best of duck typing, you need a good syntax for describing types by _usage_ , not by explicit name. Please let me know if I'm missing something, and this is actually more expressive than the documentation suggests.

<comment><USER6> Well, I like to put that another way -- I think Python is all about protocols (in the Python sense of the word protocol). I think that is what most people mean when they say Python is all about duck typing, and it communicates the concept more precisely.

The concept of 'type' is overloaded with too many meanings these days. It started out as a what-storage-to-allocate and which-instruction-to-generate (int v float) concept (FORTRAN I, variables starting with I..N are ints, others real). Deep class hierarchies muddied the waters by overlaying the idea of whether or not a class implements a particular property or method, and how to locate the property or method that you want.

Python shows us that types and protocols/interfaces are two very different thing. In Python, asking 'isinstance()' is usually a bad idea unless you are doing something very low level, low level as in next stop is a C extension. The missing predicate in Python is 'hasprotocol()'. Abstract base classes can be used to accomplish that: isinstance(foo, SomeABC), but I think the intent could be more transparent with different syntax.

<comment><USER7> > Python shows us that types and protocols/interfaces are two very different > thing. In Python, asking 'isinstance()' is usually a bad idea

Interesting perspective. This would seem to be pretty well described by parametric polymorphism with constraints (Haskell-style polymorphism with typeclasses). In that context, too, we are often well served staying as generic as possible, and asking at runtime about the type of something is a bit of a code smell (and only possible where you have a Typeable constraint available).

<comment><USER5> Yes. Haskell's type deduction is exactly what I was thinking of as I read the article. You write a function using what you need and it deducts the requirements based on usage, giving you the most general type. I think this is actually very close to compile-time duck-typing. Actually I think if you took the class declarations out of Haskell and removed the instance lines (but left the subsequent implementations), and had the compiler deduce typeclasses for you, you'd get something that felt very much like compile-time duck-typing.

<comment><USER8> If you want an even closer example, it would be OCaml with its structurally typed object system with inferred types. For example:

        # let f obj x y = (obj#m x)#n y;;
        val f : < m : 'a -> < n : 'b -> 'c; .. >; .. > -> 'a -> 'b -> 'c = <fun>

Here I defined a function taking 3 arguments, called method m on obj, passing x as argument, then called method n on the result of that, passing y as argument.

Note the _inferred_ type signature for this: the first argument is of type <m : 'a -> <n : 'b -> 'c; ..>; ..> \- i.e. any object that has a method named m (and possibly some other unspecified members - that's what ".." means), with said method m having a signature that allows us to pass some 'a, and returning another object of type <n : 'b -> 'c; ..> \- i.e. something with a method named n that accepts 'b and returns 'c. 'a and 'b' are then used as types of x and y, respectively, and 'c is the the result of f.

So effectively, this is full-fledged duck typing in the vein of Python objects, but captured on type system level.

<comment><USER5> >Note the inferred type signature for this Wow, that's really powerful. Thanks for showing me this!

</comment></comment></comment></comment></comment></comment><comment><USER9> I am glad to see that this is optional. We need languages that mix compile/parse time (static) and run time (dynamic) types, to mix what fits best to each situation.

Of course type checking can catch _some_ problems. The more extremist elements of the static types proponents seldom seem to ask the _cost_ of adding types, and making some otherwise generic/overloaded operations harder to implement (e.g. - excess clutter in some "wordy" type systems, particularly in the C lineage where declared identifier names follow the other verbiage). We need more tools that allow us to easily nail down fixed interfaces to avoid errors, but still allow flexible / dynamic / metaprogramming type code when needed, without having to jump through hoops in either case.

Don't be a static typing extremist! (or throw the baby out with the bath- water, either, I guess)

<comment><USER10> A sufficiently good static type system won't make generic operations harder to implement. It can even make them easier to implement in terms of guiding you towards good generalization techniques.

You can also do full Python-style "duck typing" statically. It's called structural typing, with native support from languages like typescript, purescript, etc. It's used a lot in web dev because it works well with Javascript's object model.

<comment><USER11> > A sufficiently good static type system won't make generic operations harder > to implement.

This is true for the JVM definition of 'generics', but it doesn't mean that arbitrary operations on a collection of types can be easily expressed with a given (static) type system. Run time type information + a dynamic type can ameliorate some of this, but that's shoehorning optional types into a static type system, and I don't think that's quite what you meant.

Think about a generic operation to diff two data structures: you need access to the members of the struct in a generic way. I don't think this is _easily_ solved with static types.

<comment><USER10> Can you give a specific example where you think you need dynamic types? The diff operation you described sounds like it could be made generic pretty easily, but I may be misunderstanding the goal.

<comment><USER11> > Can you give a specific example where you think you need dynamic types? The > diff operation you described sounds like it could be made generic pretty > easily.

How do you figure? This would require macros or runtime type introspection.

A specific example might be "serialize this json type without having to annotate the fields with how to serialize them".

<comment><USER10> > This would require macros or runtime type introspection.

Not if you structure your data using an appropriate data structure, like a map. After all, this is all structs in dynamic languages are.

> A specific example might be "serialize this json type without having to > annotate the fields with how to serialize them".

Aeson does this safely and statically using Haskell's powerful static Generics.

        data Foo = Bar Int String deriving (Generic)
        instance FromJSON Foo
        instance ToJSON Foo

You can get named fields like

        data Foo = Bar {baz :: Int, qux :: String}

<comment><USER11> Most static typing systems have no parallel to 'deriving', which is to my understanding compile-time computation (aka a macro).

<comment><USER7> "deriving" is compile time; "Generic" is runtime inspection of the shape of a value (in terms of constructor applications). Something (at least vaguely) similar to Generic exists in many statically typed languages - <USER2> (IIRC, IIUC) Java and Go.

<comment><USER11> > Something (at least vaguely) similar to Generic exists in many statically > typed languages - including (IIRC, IIUC) Java and Go.

Sure—but it's in spite of static typing, not because of it. You certainly give up any guarantees of avoiding runtime errors by detecting typing issues at compile time.

<comment><USER7> Sure, it's orthogonal to static typing (I wouldn't quite say "in spite of"). I wasn't trying to weigh in on the general topic, just to clarify what was happening where.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I still think the way Common Lisp handled typing was very convenient: Typing was basically dynamic, but one could use static typing in specific places, and one could even tell the compiler if this was for speed or for safety.

I like the idea of a hybrid type system where statically typed and dynamically typed parts coexist, OTOH, I can imagine it being difficult to implement.

<comment><USER13> Agree.

However:

        s/was/is/g
        s/could/can/g

Premature burial is a little bit scary, I take it you are doing this because Halloween is near.

<comment><USER9> Languages never die. But companies stop making new projects with them - <USER3> some number of 9s percent of companies. E.g. - FOOGOLTRAN is a five-nine dead language, if 99.999% of new projects don't use it.

<comment><USER9> I guess as long as a language is used in at least 11% of projects, it can avoid being "one-nine" dead :-)

</comment></comment></comment></comment><comment><USER14> Optional static typing is fine. But this approach to it is not good. The _correctness_ of the type information is optional. PEP 484: "While these annotations are available at runtime through the usual __annotations__ attribute, _no type checking happens at runtime._ " (Italics in original) That's just not right.

If you take that seriously, compilers can't use type information to optimize. It feels like Von Rossum is making life hard for the PyPy compiler project again. If they had hard type information, they could do serious optimizations. Guido's CPython still uses a CObject for everything internally, so it doesn't benefit much from this.

The direction that everybody else seems to be taking is that function parameters, structure fields, and globals are typed, but local types are inferred as much as possible. C++ (with "auto"), Go, and Rust all take that route. Type information on function parameters and structure fields is an important item of documentation; if the language doesn't support that, you need to put it in separate documentation or comments. But writing elaborate type declarations for local variables is no fun, and the compiler can usually infer that info anyway.

<comment><USER15> Frankly, each of your three paragraphs seems unrelated to each other, so I'm still not sure what your argument is.

1) Not type checking at runtime is exactly what people mean by static typing, because the definition of static typing means the checks are done before execution.

2) This does not make it harder to optimize, on the contrary if they generated type assertions it would considerable slow things down on the boundary of typed and untyped code.

3) C++, Go, Rust, Haskell they are fully statically typed, the only difference is they support varying levels type-inference which means you don't need to "type out the type" but it's really orthogonal to the whole optional/static/dynamic typing issue.

<comment><USER16> C++ and Go don't have type inference. All they do is set the type of new variables to whatever they're first initialized to. Type inference means figuring out the types of variables from _how they 're used_. The litmus test for type inference is inferring function argument types.

<comment><USER15> I'm sorry, but that's not the definition of type inference.

"Type inference refers to the automatic deduction of the data type of an expression in a programming language."

[https://en.wikipedia.org/wiki/Type_inference](https://en.wikipedia.org/wiki/Type_inference)

Which you'll notice C++ and Go, are listed as languages with type inference.

But you're right that they don't have as nearly as strong type inference as rust, which doesn't have as strong as haskell etc.

<comment><USER17> Rust and Haskell have very similar type inference. The only major difference is that Rust doesn't infer type signatures, but that's a design decision, not a power issue.

</comment></comment></comment></comment></comment><comment><USER18> > _For the many programmers who work in large Python 2 codebases, the even > more exciting news is that mypy has full support for type-checking Python 2 > programs, scales to large Python codebases, and can substantially simplify > the upgrade to Python 3._

Woah! Excellent news. Really cool that they found a way to use this opportunity to bolster Python 3 migration.

</comment><comment><AUTHOR> Original author here; I'm happy to answer any questions about the mypy experience!

<comment><USER19> Does Sphinx (or any other automated-documentation tool) read the MyPy annotations, or would I have to type them in twice, in different syntaxes, if I wanted types in my docs + linting?

Or does type documentation not matter that much, once it's being enforced by a tool?

<comment><USER20> there is at least this, others might also exist [https://pypi.python.org/pypi/sphinx-autodoc- annotation](https://pypi.python.org/pypi/sphinx-autodoc-annotation)

</comment></comment></comment><comment><USER21> I am extremely excited about this. I already verify parts of my applications, but better support (especially in libraries) will make this that much more useful. It's an essential part of the checking pipeline (with pyflakes, pep8, McCabe, etc).

</comment><comment><USER22> Started to use python recently, coming from Go, I found:

\- the official docs are useless, return types are often not documented (wtf ?) and docs aren't structured and clean. Python documentation is a giant mess.

\- mypy is a god sent I used it from day one to document my Python code, but it needs better integration with python doc tools, 3rd party linters and co.

I'm ok with optional type checking. A team can make it mandatory during continuous integration while not breaking legacy code, but I hope mypy will be directly integrated to Python in the future and not a 3rd party tool.

<comment><USER23> Could you give some examples of functions in the standard library (or built- ins) which don't document their return types?

<comment><USER24> I sometimes have to write some python script. The documentation documents return (and expected) types, but in a manner that is a bit alien to C or C++ programmers. It is more talky. It is probably in dynamic nature of python.

Instead of a list of possible returns with some kind of prototypes you may be left with description: "The returned object is always a file-like object whose file attribute is the underlying true file object.".

See for example documentation for tempfile.NamedTemporaryFile [1]. This time possible returns are not in the separate paragraph as is in many other cases. You can't click anything expect TemporaryFile(), so you have to search for proper reference. The information is there, but instead of quick glance you have to parse and search more text.

[1] [https://docs.python.org/3.6/library/tempfile.html](https://docs.python.org/3.6/library/tempfile.html)

</comment></comment></comment><comment><USER25> @OP(tabbott), you can add to "Benefits of using type annotations":

Improves IDE integration, especially IntelliJ PyCharm's jump-to-source

</comment><comment><USER10> > It has a far lower false positive rate than the commercial static analyzers > I've used!

Hoo boy. That's not a good thing. A consistent type system doesn't have "false positives". Reading between the lines, this means "the type checker is incomplete and allows incorrect types."

What is the story here with constraints, polymorphism, etc?

</comment><comment><USER26> I wish PEP 484 put more thought into backward compatibility with Python2.

Currently you need to import things like Callable, Tuple and these don't exist in Python2. It is especially odd since I am using MyPy comment syntax, so MyPy needs import statements even when all types are inside comments.

I like the way Haskell puts type information above the definition.

<comment><USER27> In Python 2 and also in Python 3.4 and earlier, you get Callable, Tuple, and the rest from the `typing` module on PyPI: [https://pypi.python.org/pypi/typing](https://pypi.python.org/pypi/typing)

This is a direct backport of the same `typing` module that's in the stdlib starting in Python 3.5.

(I'm one of the mypy core developers and work at Dropbox. We're using PEP 484 and mypy on a lot of Python 2 code!)

</comment></comment><comment><USER28> Why doesn't the import cycle trick work with the Python 3 syntax? This doc seems to suggest that it should: [http://mypy.readthedocs.io/en/latest/common_issues.html#impo...](http://mypy.readthedocs.io/en/latest/common_issues.html#import- cycles)

<comment><USER29> It should work with the Python 3 syntax if you quote your type annotation. I.e.

      def f() -> "Bar": ...

instead of

      def f() -> Bar: ...

(This is normally used for forward references.) This makes it slightly less nice, but not a terrible workaround overall.

</comment></comment><comment><USER30> i've been skeptical about mypy's usefulness. i'm absolutely thrilled to be proven wrong here. thanks for blazing the trail.

</comment><comment><USER31> Here's what I don't understand -- every discussion about static typing is full of people saying static typing is so good and useful. Everyone i talked to, everyone i work with, we all prefer static typing. And yet... Javascript and all that.

<comment><USER32> Javascript runs in the browser natively. It's primary advantage is that you don't need to install anything other than the browser. The reasoning behind node.js is that a lot of front end engineers no longer need to learn and use a seperate language for the server and maybe even can reuse libraries between the server and browser.

Javascript is the bash of the internet. It's not that great but it does have a "killerapp".

</comment></comment><comment><USER33> Nice, how come some of the type names are capitalized? When the builtins are lower-case? e.g.: List compared to list()

<comment><USER29> Good question! There are separate capitalized types for List, Dict, etc provided as part of the `typing` module in order to let you specify element types. Types are all normal Python expressions, so if you wrote `list[int]` you'd get a runtime error, because `type` objects (i.e. the `list` class) aren't subscriptable.

</comment></comment><comment><USER34> Don't see c/c++ target in the roadmap, which seems like an ideal use case for typed python besides correctness. Thoughts?

<comment><USER35> What ? You mean like export to c/c++ code? Isn't python too dynamic for that ?

<comment><USER34> I'll say python isn't any more dynamic than ruby and groovy, and they have fairly stable and usable static compile target release/ports [1]. Python has a few [2] attempts, but none of them is close to stable or really useful.

[1] [https://crystal-lang.org/](https://crystal-lang.org/)

[http://groovy-lang.org/releasenotes/groovy-2.0.html](http://groovy- lang.org/releasenotes/groovy-2.0.html)

[2] [https://github.com/shedskin/shedskin](https://github.com/shedskin/shedskin)

[https://github.com/codeblazer-io/blazescript](https://github.com/codeblazer- io/blazescript)

[https://github.com/serge-sans-paille/pythran](https://github.com/serge-sans- paille/pythran)

<comment><USER29> Don't forget Cython [1]! My understanding is that it's quite useable (though it unfortunately uses a different static type system/syntax than mypy).

[1] [http://cython.org/](http://cython.org/)

<comment><USER34> Didn't forget it, just didn't include it since to me, it's more like a totally different (and not pretty) language that tries to look like python. I should however include Nuitka [1] since it is fairly usable, it's just the generated version isn't much faster than its interpreted python version.

[1] [http://nuitka.net/](http://nuitka.net/)

<comment><USER36> Why does the same not apply to Crystal then?

<comment><USER34> Guess you can say Crystal is a totally different language as well. It's just to me, Crystal still has the same feel as ruby and Cython doesn't. Again, it's just my opinion, I won't argue if you feel otherwise.

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> Type annotations and mypy are a great idea, sure. But IMO the low hanging fruit is from static analysis tools like pyflakes, prospector, bandit. Most projects don't even capitalize on these and your time is better spent remediating the findings from these and/or carving out the exceptions where necessary.

</comment><comment><USER38> This sort of reminds me of how TypeScript got started. Bracing to hear about TypePy in coming days :P

<comment><USER39> And what exactly do you think they would add to Python that is not already there?

</comment></comment><comment><USER40> Does PEP 484 plan to allow runtime reification of types (ie type information during runtime via reflection aka Java/C#)? I made a cursory check of it and it is unclear but I would assume no.

I know some may disagree but I have found runtime reification of types fairly useful in the Java world (partly because Java does not have good code generators like OCaml/Haskell and partly because Java is not that expressive).

</comment><comment><USER41> Mypy is great, but it still has some ways to go. For instance, the type checker is thrown off by descriptors (__get__ and __set__ are ignored). Further, the typing module needs some work. The types in the module are sufficient for annotating simple programs, but the more "meta" the programming becomes the more walls will pop up.

</comment><comment><USER42> IMO adding static types is good step but it sort of misses the point of modern type systems.

The good thing about types is not that you can just annotate (or not with good inference not) and validate that some type is what you expect it to be. It's that with a proper type system you can develop better abstractions.

</comment><comment><USER43> Interesting. I had blogged about mypy here, a few years ago:

[https://jugad2.blogspot.in/2012/12/mypy-python-variant- with-...](https://jugad2.blogspot.in/2012/12/mypy-python-variant-with-goal- of.html)

but had not tracked it much after that. Must check it out again.

</comment><comment><USER44> Can someone point me to a live, public instance of Zulip that I can use to experience a real demo?

<comment><USER45> [https://zulip.tabbott.net/](https://zulip.tabbott.net/)

It's amazing. Zulip is Slack done right. Their threading/light-weight topic approach is second to none.

</comment></comment><comment><USER46> The python 2.x "comment" version should have been parsed from the docstring...

</comment><comment><USER47> It bothers me when the constructs of the language are not used for things like this. Example, the syntax for a list of ints is `List[int]` as opposed to `list(int)` where list is an actual fn in python and so it makes more sense. Obviously list(int) has far different meaning, but List is a totally foreign thing in Python. I think it makes sense for a DSL to remain as close to the parent as possible.

Another example of this is most of the prismatic/schema-esque frameworks for python to do validation on datastructures. Instead of saying foo must be { "name": "String" } (where there is a framework-specific meaning behind the literal word "String") we should take advantage of the built-in types and say {"name": basestring}.

End rant.

</comment><comment><USER48>
        sum_and_stringify(nums: List[int]) -> str:

This looks so bad. I think Python is making a big mistake with this.

The commented version is much more acceptable.

<comment><USER49> Its basically the same syntax as Rust, which I honestly like. I mean, I didn't like the syntax to begin with (I have always been a stickler for how name: type introduces a superfluous colon over type name syntax) and using two glyphs for returns is horrible, but since several languages are now doing this, if you are _going_ to do it, you might as well keep it consistent.

<comment><USER48> ddfisher up there is already talking about stuff like

\----

It should work with the Python 3 syntax if you quote your type annotation. I.e.

      def f() -> "Bar": ...

instead of

      def f() -> Bar: ...

\---

Yeah, you need to write `from typing import List` to get the generic List class that you can parameterize with an item type. As you pointed out, you can use the builtin lowercase-l list without importing anything, but that doesn't allow you to specify the item type.

\---

imo, this is brutal. I'll just wait and see whether I'm proven right or wrong, but the extremely poor aesthetics of the whole thing bode badly.

</comment></comment></comment><comment><USER25> Sorry for posting this issue here:

python3 type_annotations.py

        def sum_and_stringify(nums: List[int]) -> str:

NameError: name 'List' is not defined

EDIT: Solved: Either just list or List[int] with import:

from typing import List

Thanks for all the help guys! By the way I took the example from the mypy page. A classical case of 'critical line missing from example code' (as perfectioned by Bjarne Stroustrup back when)

<comment><USER35> I think you have to import that.

<comment><USER25> import List??

At least this works: def sum_and_stringify(nums: list) -> str:

<comment><USER50> The built-in constructor is `list`, not `List`.

<comment><USER25> Thanks for all the help guys! by the way I took the example from the mypy page

        def sum_and_stringify(nums: list[int]) -> str:

TypeError: 'type' object is not subscriptable

so either just list or List[int] with import, got it.

A classical case of 'critical line missing from example code' (as perfectioned by Bjarne Stroustrup back when)

</comment></comment></comment></comment></comment><comment><USER51> ...and so we risk shuffling even further away from what made Python great. Simple pragmatism. Now in addition to unicode hair tearout, xrange forcefeed, dict access strait jacket, print function dogmatism, and extraneous unused async library which was already implemented 14x elsewhere, we are moving towards strictly typed Python?? If you want all this stuff, surely there is C, Ocaml, Go, or Typescript, etc, all of which are much faster?

<comment><USER52> It is a common misconception that typing makes stuff more complicated and inconvenient. Some type systems are quiet _bad_ (not powerful enough, so they do more harm than good), but that does not mean that the idea of typing itself is bad, but their implementation is. In my opinion Python kicks ass, because of world-class libraries for nearly anything, and not because it's dynamic (a broad term, I would say it's strongly typed) und you do not have to declare types (which can often be inferred).

You listed 4 specific languages, but the following things are each inconvenient in them:

      - C: it's inconvenient to implement a quick prototype
      - Ocaml: it's inconvenient that the stdlib is so small
      - Go: it's inconvenient for scientific/numerical code
      - TypeScript: it's inconvenient to run server-side

Obviously you can do everything in any language (Turing, blabla), but the question is, how much effort (time) does it cost.

Python rocks in all of them (edit: the _big_ exception being frontend webdev), in particular for quick prototyping. I think mypy is an exceptional and fine contribution to the eco-system and I really appreciate their effort.

<comment><USER53> Being in the middle of a struggle with Javascript tooling (Javascript, ES5 v/s ES6, typescript, webpack v/s System.js, shims, pollyfils, npm downloading the internet, etc, etc) I can't but imagine that there should be a better way.

How much I would like Webassembly to be ready to open the gates to other languages on the frontend land. Anyone here has more information about webassembly / python on the browser? I would love to know what is the current state of the art of running python on the browser and contribute to make the dream come true.

I have on my radar Brython [0], py.js [1](seems to be abandoned) and pypy.js [2]

[0] [http://www.brython.info/](http://www.brython.info/) [1] [http://pyjs.org/](http://pyjs.org/) [2] [http://pypyjs.org/](http://pypyjs.org/)

<comment><USER54> [https://github.com/kovidgoyal/rapydscript- ng](https://github.com/kovidgoyal/rapydscript-ng) [https://github.com/QQuick/Transcrypt](https://github.com/QQuick/Transcrypt)</comment></comment></comment></comment>


How Can I Find a Coffee Shop That'll Actually Let Me Sit and Work for Awhile? - <AUTHOR> http://lifehacker.com/5983330/how-can-i-find-a-coffee-shop-thatll-actually-let-me-sit-and-work-for-awhile <comment><AUTHOR> In my experiences, coffee shops, even ones like Starbucks, are pretty lenient. I've spent 2-3 hours at them. As for the public library, the one nearest to me doesn't have WiFi, and I'd probably just be at home anyways if I'm that close, the one near my school makes me have a library card, and I don't feel like paying for it since I'm not actually located in the same city, and the next nearest one is over half an hour away. Plus, libraries don't serve coffee.

</comment><comment><USER2> They're called public libraries. Quiet encouraged. Most have WiFi.

</comment><comment><USER3> You're first problem is actually caring. I walk into coffee shops all the time and stay for a few hours while working on the road.

</comment><comment><USER4> Walk in. Buy something. Ask them.</comment>


Web of Documents (2019) - <AUTHOR> http://blog.danieljanus.pl/2019/10/07/web-of-documents/ <comment><USER2> I think I understand what the author is trying to say. For me the feeling that you are browsing a "web of documents" is that you know that you are clicking around for information. It is very basic. You look at and read a page with some links. You find something interesting and click on a lick. This produces a deterministic action: another page loads with some links. That's it. It might look slightly different but it doesn't move around when components are loading dynamically, no pop-ups, no red "1" badges that try to grab your attention. It will either load slowly or it will load fast, it won't alternate between the two while loading.

The main focus is the content of the document and the other content it leads to. Not the style, the features, the tech that it uses to load the content. I compare it to books. Most books are the same, predictable. They will have text and some images on pages. When turning a page it will show another page. It wont suddenly ask you to log in or go buy another book in the middle of this one. The covers of the books are slightly different but the basic function is the same. That's it.

<comment><USER3> _it doesn 't move around when components are loading dynamically_

Images that don't have width and height attributes always did that. Not adding those attributes to an img tag was considered a sign of a poorly made website in the very early 2000s. I think it _might_ have been the origin of the term "layout thrashing".

<comment><USER4> Sidetrack: I really miss when designers added h*w. Even mobile apps do it now causing the button under your finger to jump as you're tapping...

Feels like such a step backward

</comment></comment></comment><comment><USER5> Daniel's sentiments resonate with me. I would add 1 additional restraint:

4\. Every document is version controlled

That way, as Daniel puts it, "[the document] will not magically alter its contents tomorrow". Or if it does, I can see a history of what was altered. Ideally, this would somehow be built into the protocol/browser rather than be a burden to the publisher.

Also, maybe after a certain amount of time I can no longer modify my document. If I'm the New York Times, this means when I publish a news article document, and it contains an advertisement, that same advertisement forever lives on that document - just like physical newspaper.

<comment><USER6> Interestingly, the page as I just read it does not (no longer, I guess) mention "version control". Probably the author changed their mind towards simplicity. This is funnily, ironically meta.

That said, I agree with the author and discussed the topic with friends for years.

On the "do you practice what you advocate?" side, my freelancer company website is, since day one 8 years ago, a totally static (no script, no cookie... except the one my hosting provider added without letting me options, I will quit them some day) collection of documents with readable stable URLs. [https://fidergo.fr/](https://fidergo.fr/) And the smaller English language [https://fidergo.com/](https://fidergo.com/)

The part detailing dozens of software projects is generated in advance from a structured data store into static pages uploaded to server. [https://fidergo.fr/expertise](https://fidergo.fr/expertise)

Version-controlled, scripted deployment.

Safe for me to serve, safe for you to browse and read.

That is the web of documents.

<comment><USER7> > Interestingly, the page as I just read it does not (no longer, I guess) > mention "version control". Probably the author changed their mind towards > simplicity. This is funnily, ironically meta.

Author here. The article has not been edited since it was originally published. I agree that version control is an important topic, and I applaud efforts such as IPFS; it is, however, tangential to the main point of "documents vs applications" that I was trying to make.

<comment><USER6> Oh, sorry, thanks for correcting. That line from a commenter was actually an additional idea, not from you. I totally agree with you. Bundling a global visitor-visible version-control system would bring the whole idea closer to the never-implemented xanadu project.

</comment></comment></comment></comment><comment><USER8> The author states that in an ideal "web of documents", we would have (1) only GET requests, (2) no (java)scripts, and (3) no cookies. While I agree with (1) and (3), I disagree completely with (2).

Having Javascript enables amazing things like _interactive documents_. For example I would consider [1] a document, despite the fact that there is Javascript running. What a wonderful way to interact with and get a better understanding of a Voronoi diagram! Or how about the wonderful interactive demonstrations of graph searches at [2]? To me, things like this are part of what makes the web platform fantastic.

Earlier in the article, the author writes:

"A document is stateless. It exists in and of itself; it is its own microcosm. It may be experienced interactively, but only insofar as it enables the experiencer to focus their attention on the part of their own choosing; the potential state of that interaction is external to the document, not part of itself."

I think that the two interactive javascript-powered articles I linked comply with this. Ruling out scripts entirely is too heavy-handed - perhaps a nice middle ground can be found somewhere.

[1]: [https://strongriley.github.io/d3/ex/voronoi.html](https://strongriley.github.io/d3/ex/voronoi.html)

[2]: [https://www.redblobgames.com/pathfinding/a-star/introduction...](https://www.redblobgames.com/pathfinding/a-star/introduction.html)

</comment><comment><USER9> I've been thinking a lot about this. Over the past week or so, I first made my blog browsable with cURL[0], then plain TCP sockets[1]. I learned a lot through this process, and relearned some things as well:

1\. HTTP/1.1 is valuable. With the move to HTTP/2, we lost the principle of "simple things should be simple, complex things should be possible" (Alan Kay). All things in HTTP/2 are complex. I can make an HTTP/1.1 client on the command line with netcat.

2\. Serving documents is incredibly simple[2] and safe (once you handle path vulnerabilities :D ).

3\. We should extract web browsers from the behemoth JavaScript VMs we're all running now. I'm all for having portable VMs, and I like the direction WebAssembly is headed, but probably 80% of what I do on the web could be accomplished using an order of magnitude simpler software, accessing read-only documents.

4\. Markdown and other human-readable formats are awesome. I used to think writing my blog in HTML had the least dependencies, but now I realize it makes you depend on a browser to render it, and that's a _huge_ dependency. Markdown can be read as-is and therefore is almost dependency-free.

So I agree with the author here, and this is how I think we get there. Someone should make a stripped down web browser with the following attributes, or something similar:

1\. Only speaks HTTPS

2\. Only GET requests

3\. A few choice headers, like Range for streaming video.

4\. No JavaScript, or any Turing complete language at all.

5\. Minimal CSS, ie colors, font sizes, flexbox. No animations (you don't have a language to trigger them with anyway).

6\. Can probably throw away some HTML elements as well.

The nice thing about this approach is that sites made to work with this browser will still work in normal browsers. They'll just be super fast, low on resources, secure, and private.

[0] [https://anderspitman.net/17/#curlable](https://anderspitman.net/17/#curlable)

[1] [https://anderspitman.net/19/#netcatable](https://anderspitman.net/19/#netcatable)

[2] [https://github.com/anderspitman/newb-server- go](https://github.com/anderspitman/newb-server-go)

<comment><USER10> > With the move to HTTP/2, we lost

Fortunately, we haven't lost anything yet on that front as HTTP 1.1 is still supported by practically all servers and clients.

<comment><USER9> Yes, that's actually what I'm trying to convey, is that we shouldn't see 1.1 as something to deprecate. I'm in favor of maintaining that compatibility.

</comment></comment></comment><comment><USER11> What the article describes is gopherspace, which believe it or not still exists. And believe it or not, is experiencing a resurgence. It's too bad major browsers gave up on gopher:// because as we are seeing now in this and other laments for the old www, we lost something that we didnt have to lose. Gopherspace--check it out.

<comment><USER12> best browser for gopherspace, if I were curious? best search engine?

<comment><USER13> If you're just curious, there's a gopher->http gateway:

[https://gopher.floodgap.com/gopher/gw](https://gopher.floodgap.com/gopher/gw)

And a search engine:

[https://gopher.floodgap.com/gopher/gw?=gopher.floodgap.com+7...](https://gopher.floodgap.com/gopher/gw?=gopher.floodgap.com+70+372f76322f7673)

</comment></comment></comment><comment><USER14> The case for "forking the web"?

What if we just released a new browser that flat out refused to load any resource outside this definition?

Would sort of be like the parallel worlds of gopher and the web for a while. I think it would be interesting to have a "web fork" that was just for documents not apps.

<comment><USER15> IPFS and blockchains are the technological solution here.

Many applications are already being developed to create this new Web3.0 document-centric world (I'm creating one of them!) which will provide a "way" to have the original Tim Berners Lee web once again be possible.

...and not only that but it'll also be decentralized and 'uncensorable'!

<comment><USER16> IPFS is not uncensorable. The protocol is based on a DHT that allows anyone to find what IP addresses are hosting a particular content, so it's possible to take them down.

It only appears uncensorable because it's not (yet?) popular enough for states to care about it.

And for blockchains to be uncensorable, you need the content to be on-chain, which doesn't scale. (because, if the content is off-chain, then you need an external solution to host the content, so the blockchain didn't solve the problem)

<comment><USER15> You're claiming that if a piece of information has an identity that makes it reachable, then that makes it censorable too, but you left out what would be required to make that censorship happen. The gov't would have to require the IPFS codebase to support a 'blacklist table' of hashes, and then make it illegal for a server to run a codebase without using the 'updated' latest table. The the gov't would have to come up with a mechanism where they maintain and update this blacklist and disseminate it.

Meanwhile, if I want to make a blacklisted doc 'available again' all I'd have to do is add one bit or byte to the end of it, and the hash would change completely.

Right now one single person at one single tech company (like a Twitter employee) can literally ban someone for life, for perfectly legit political speech.

IPFS is the best-in-class effort to solve all that, and I'm actually a guy building a node that will go on the IPFS network.

<comment><USER16> > You're claiming that if a piece of information has an identity that makes it > reachable, then that makes it censorable too, but you left out what would be > required to make that censorship happen. The gov't would have to require the > IPFS codebase to support a 'blacklist table' of hashes

No, it only has to take down servers hosting its content.

> all I'd have to do is add one bit or byte to the end of it, and the hash > would change completely.

This is unrelated to my point, but a nitpick: IPFS uses a rolling/chunking hash, so one could blacklist chunks of a file; so it's not as easy as adding a byte at the end.

<comment><USER15> 1) Regarding the gov't taking down servers publishing hashes it doesn't like, yes that's exactly what I said they'd have to do, if you go back and re-read my prior post. Glad you agree. But like BitTorrent or Bitcoin, they'd have to basically shut off the whole internet to disable it. Not gonna happen.

2) Regarding chunking in IPFS, the fact that files are chunked actually increases the burden on any authority attempting to implement a blacklist of hashes, and so that's in agreement with my points.

Also if someone truly wants to fight censorship you'd just symmetric encrypt the data using a publicly available key so that it DOES change all hashes of ALL _chunks_ every time you encrypt with a different key.

And encrypting the same data under many different keys (creating different copies of whole file, is also my proposed solution to the problem of "Proof of Replication" in the IPFS system.)

</comment></comment></comment></comment></comment></comment><comment><USER17> > This page is a document. Thank you for reading it.

 _Opens Dev tools, views <head> tags, and "Source" tab looking for javascript_

Nothing there. Well done, author. All too often I read articles like this on Medium and laugh at the authors perpetuating the problem they want to solve. I love clean, well styled, beautiful looking static blogs. I'll have to start one someday.

</comment><comment><USER18> I appreciate the sentiment, but the prescription is extreme. The technologies mentioned beyond HTML: CSS and JavaScript (yes, even Javascript), can be used to enhance the presentation of the document, and more importantly can do so without altering the document itself (ie the HTML). We need to be encouraging better design and implementation practices, namely graceful decay, and can do so without sacrificing features that improve readability and accessibility, such as syntax highlighting or dark color scheme variants.

<comment><USER19> Can you give an example where JavaScript would "enhance the presentation of the document"?

You mean like scroll-jacking? Some script that prevents me from copying and pasting? Something that loads images later for some reason and shifts everything around?

I don't mean to be facetious, I am genuinely curious what you mean. In my experience JS has been nothing but a detriment (for reading documents, that is), and I have it disabled on all of my computers.

<comment><USER20> This is a good example where I think JS adds substantially but is still document-y: [https://www.redblobgames.com/grids/hexagons/](https://www.redblobgames.com/grids/hexagons/)

<comment><USER21> This is amazing

</comment></comment></comment></comment><comment><USER22> >Not even to enrich a document, such as syntax-highlight the code snippets. This one may seem too stringent, but I think it's better to err on the safe side, and it's very easy to enforce.

If the enrichment rules are known ahead of time, there is no reason you can't just "hard code" the colors or formats into the document.

<comment><USER23> I think that's what the author was going for. Syntax highlighting and other improvements would be "baked" into the document by the server and the final document would be served to the client. All without the use of client side scripting.

<comment><USER24> You can do this now with some static site generators.

</comment></comment></comment><comment><USER25> Maybe I'm missing something, but I don't understand the authors thesis here. He seems to have a problem with when he navigates somewhere and instead of receiving an expected block of pure text, he gets that along with a whole bunch of tracking/impressions/pay walls.

Sure, I get it, that's a problem, but it's not a _document_ problem. The web of applications let you _actually do stuff_. Yeah sure there's a ton of crap, but cherry picking only the news sites as a reason to remove PUT requests seems like the total wrong approach.

</comment><comment><USER26> I sympathize with the author, but who really likes a 100% web of documents? Me and a couple of other nerds. Is that enough to reach critical mass? Vast majority of internet users loves the _engaging_ , interactive, animated web and notifications. It has armies of psychologists working on it to make it addictive, then feed them ads and sell their data. We would be quite alone in a web of documents. A voluntary exile. I would personally like it, but who would finance it?

<comment><USER27> > A voluntary exile. I would personally like it, but who would finance it?

Us. All of us. All hail mesh networks.

</comment></comment><comment><USER28> Such a good post; I really agree with so many of the author's points! The following tidbit in particular is so powerfully true:

> A document is safe. A book is safe: it will not explode in your hands, it > will not magically alter its contents tomorrow, and if it happens to be > illegal to possess, it will not call the authorities to denounce you. You > can implicitly trust a document by virtue of it being one. An application, > not so much...

</comment><comment><USER29> I keep seeing (and mostly sharing) sentiments like this, but a couple of things to note:

\- Sets of proposed features vary (happens to both lightweight WWW and modernized Gopher proposals). I guess a more viable approach may be a less strict one than composing such a set. For instance, a search engine for such websites was mentioned in another comment here, and I keep thinking about a web directory for that, but perhaps either of those would be more useful if it was able to detect (and filter by) features required by a website, rather than a single flag saying whether it's usable with a particular set of features.

\- Occasionally it's suggested (in this case both in the article and in the comments) that browsers only supporting documents would help somehow. Yet there's a bunch of lightweight web browsers (even I wrote a couple), as well as combinations such as FF+noscript+uBO+Stylus, which may be nicer to use, but don't seem to affect the overall situation beyond "please enable JS" and "best viewed in IE6" messages.

</comment><comment><USER30> I think JavaScript would be fine as well, as long as you disallow fetch / XMLHttpRequest and third-party resources.

</comment><comment><USER15> I agreed with and enjoyed this 'document'!

I think the new Web3.0, and blockchains, and IPFS are going to lead to a new web that is more like it was in the old days where people were sharing actual documents.

I'm the creator of 'quantizr.com', which also fully adheres to your sentiments, but also a belief that documents themselves should be granular (i.e. quantized).

The IPFS 'interpretation' of my quantizr concept would be something like saying a 'document' can have a version stored on IPFS that is a specific immutable copy.

</comment><comment><USER31> > We don't have a Web of Documents anymore. These days, the WWW is mostly a > Web of Applications.

Yes! It's 'SaaSS' \- as defined by Stallman, not 'SaaS'.

"On the Internet, proprietary software isn't the only way to lose your freedom. Service as a Software Substitute, or SaaSS, is another way to give someone else power over your computing.

The basic point is, you can have control over a program someone else wrote (if it's free), but you can never have control over a service someone else runs, so never use a service where in principle a program would do.

SaaSS means using a service implemented by someone else as a substitute for running your copy of a program. The term is ours; articles and ads won't use it, and they won't tell you whether a service is SaaSS. Instead they will probably use the vague and distracting term "cloud", which lumps SaaSS together with various other practices, some abusive and some ok. With the explanation and examples in this page, you can tell whether a service is SaaSS."

Source: [https://www.gnu.org/philosophy/who-does-that-server- really-s...](https://www.gnu.org/philosophy/who-does-that-server-really- serve.en.html)

</comment><comment><USER32> The author and their sympathizers can easily refrain from using JS and other technologies they don't like in their own sites, and preferentially give attention to such sites. No technology changes are required for that, except that as another commenter noted, it would be helpful to have a search engine that prioritizes such documents.

The problem the author has is not a technology problem, it is that sites restricted to just such documents are not especially popular with most users.

People who wish that interactivity etc had never been added to HTML are misguided. (I'm not sure if the author falls into that category.) HTML competed with other technologies (e.g. Flash, ActiveX, native apps); when authors felt overconstrained by HTML they used those instead. If interactive apps were all Flash and ActiveX and native today, and Web apps didn't exist, would that be a better world? Certainly the Linux desktop would be far less usable.

</comment><comment><USER33> I think the way forward is even more powerful and interactive "document". Imagine for example a car manual that also lets you run diagnostics or tweak the HUD. And also third party "web pages" that can do the same thing if you allow them to. Imagine searching for a baking recepy, then with a click of the button, the "web page" connects to your baking machine and sets the ingredients. Imagine a document about some math topics, with interactive models that helps you understand the concepts (that actually exist today).

<comment><USER34> We hit problems of ownership, control and scope here. I want a tool I can use to find a baking recipe and configure my baking machine automatically. I want that tool to be entirely independent of the sites it pulls recipes from, and of the machines it configures. From this point of view, I want the recipe sites to be dumb documents, preferably in machine-readable format. Similarly, I want my baking machine to be a dumb telemetry/configuration endpoint.

In this baking example, there are three pieces of the puzzle. Recipe source, configuration endpoint, and the brain in the middle that uses one to work on the other. I want that brain part to be independent - but you can easily see how the recipe site and the machine vendors would each like to own the brain part exclusively. That's why we can't have nice things on the Internet - nobody can accept their role as a _service provider_ , everyone wants to be a platform, the landowner of their digital sharecrop.

<comment><USER33> That would be even better. A static document with an URL. Then you "swipe" the URL from your phone/pad to the baking machine, which fetches the URL and reads the marked up recipe. You then confirm the ingredients on the baking machine, and it starts baking

I however want both "apps" and semantic "documents". Launching an app by typing an URL is powerful. And on Android you can now add an web app to the home screen.

We might not want the recipe to have the same capabilities as the "app". Maybe the apps should be closer to the OS, and "documents" opened in a reader app (browser).

One problem with the "semantic web" is that the added markup feel alien and too verbose. It was designed to be used with web page builder apps. But I and many others still prefer to code the HTML manually, with the help of a powerful editor (with autocomplete and macros). "Structured data" gets too hard to read by source. An idea is to replace the many span and div elements with actual semantic elements.

In another post I ranted that nothing had really changed for "documents" on the web in the last 20 years. We are practically standing still, without any innovation. Probably due to browsers being overly complex and hard to develop. I think the time is ripe for a "document only" web browser, and we can start innovating again! For example, the enterpise market is still using word documents, some use alternatives like Google docs. But web "documents" would be far more powerful. Instead of e-mailing files, you should just share a URL.

I'm currently working on an Editor for making web documents (but also for making web apps). I've put a lot of thoughts to how enterprise can use my editor to make web documents instead of word files and PDF's. Almost everyone are using the web today, but very few people actually make web "documents".

</comment></comment></comment><comment><USER35> Obvious question that's been asked a million times: who the hell is gonna pay for this web of "documents"? Producing and distributing "documents" costs money; this web of "documents" is all well and good for hobbyist stuff (and we do still have a subweb of documents of personal websites) but breaks down when people rely on it to put bread on the table.

<comment><USER36> The article for not ask for ad-free documents. Admittedly, personalized ads do not work well without Javascript.

<comment><USER35> The Web of Documents would eliminate subscription models entirely (unless we resort to HTTP Basic Auth), so that leaves non-personalized advertising as you said. Unfortunately that seems to only work when your content has a specific audience that can be profitably targeted without personalization, plus being notable enough so that advertisers suitable for your audience would notice your site and partner with you. Doesn't work for most ad-supported websites if you ask me.

<comment><USER37> > Unfortunately that seems to only work when your content has a specific > audience

Advertisers find general magazines and TV still interesting enough, without any personalization.

<comment><USER35> There are way more random internet publications than TV stations/channels and sustainably run physical magazines.

</comment></comment></comment></comment></comment><comment><USER38> Not that I dislike the idea of a web of documents, but I find it ironic that the page (application?) it's being debated on would not be possible without some of the capabilities the author is suggesting to restrict.

</comment><comment><USER39> really beautiful, simple blog layout! the background color should be a tad bit less saturated though, imo. also, that blurring effect is a little too much for my poor eyes. but i love the simplicity of it!

<comment><USER7> Author here, thank you!

I'm not much of a designer so I just reused a color scheme I liked that I found on ColourLovers.

</comment></comment><comment><USER40> I love the idea of a web of documents, but I would love it even more if it was a web of documents you could edit collaboratively.

First class support for Google Docs/Sheets/Slides style creation, with a clean default read mode would be perfect. An open web born out of Libreoffice rather than out of Blink/WebKit/Gecko. Secure, federated document access with easy long term caching/archival of static versions.

</comment><comment><USER41> While I like the idea I feel like it's misplaced. Hand writing documents was acceptable until we got typewriters. Black and white text was acceptable until we built color displays. Paper documents were acceptable until we built word processors. Digital documents were acceptable...until we built the Web of Applications.

I do not see documents and applications as two separate things. I think an application is the inevitable next step towards our goal of disseminating information as efficiently as possible. That's why it's called hypertext - it's meant to be a better version of plain text documents.

The author's biggest complaint is "applications pretending to be documents," such as journalism sites that implement monthly article caps. Sure, but in the old days you had to pay for the newspaper too, didn't you? Paywalls are not a result of the "Web of Applications" as much as they are a corporate attempt to adapt to a new medium. Nobody will publish documents for free unless it is a hobby or passion; in order for there to be worthwhile documents churned out every week or so, someone has to get paid. The author seems to presume that news orgs would simply publish their documents for free if the Web only enabled GET requests. I have extreme doubts about this.

<comment><USER15> I think Daniel's ideas are very similar to the sentiments of pretty much everyone fed up with Social Media and their censorship and the fact that a few monopoly tech companies control the flow of information nowadays (FANG+Twitter), rather than the original free "web of documents" Tim Berners Lee created.

Web3.0, IPFS, blockchain, etc. are what will end the 'non-document-capable' web that we all seem to now be experiencing.

For example if you go to someone's blog, it's on some site, and if that site goes away, that document is gone forever. That's the problem. We need an internet that is more like a massive public blockchain than a small number of monopoly sites trying to feed you enough stuff to collect information to sell about you.

</comment></comment><comment><USER42> Don't RSS feeds already provide an experience similar to the one outlined in the article?

<comment><USER26> RSS is a good illustration of the problem. In theory, it can be used to do that. In practice, it isn't because >Read the full article<. RSS used to be a solution for people who liked simple content. But there's no guarantee that you will get the whole article.

</comment></comment><comment><USER43> Agreed with the poster on many points. I want a web where I can return to a website at any given time and expect to see the same content that was present before.

I think a version controlled web would be sweet, like git internet.

Publishing a page ultimately creates a commit hash. Removal of published commits is not a thing. Only forward changes. Mess something up? New commit.

When referencing a page from another, a commit hash can be specified if desired, however, linking to a page/accessing a page without a commit hash resolves the most current (think master branch) page/commit hash.

When accessing a page in browser, you should have the ability to rollback to a previous version of a page if so desired. Since all dynamic content and linked-out content is based on commits hashes (resolved at time of publish), you now have a way to receive all content you did before.

I like the idea of a static HTML/CSS only idea for pages and ditching JS mostly due to what crap the web has become filled with, like author mentions, paywalls and tracking.

At the same time, I think all can be accomplished without dynamic scripting as long as pages are hosted privately (as things like server logs can be inspected) and websites are able to set/retrieve session storage on client- side. Not sure how to solve for that.

I always land on the whole thing being decentralized and everyone participating holds many pieces like bittorrent where there is hash authenticity. The hashing to client lookup could be authority type servers (like cert authorities/trusted tor nodes) as trackers. The problem with this is nobody wants to have crap stored on their computer to use the internet.

Private, trusted nodes seem to me to be the better option, but they would need to be locked down like a root certificate authority. No logs either. Just multi-redundant, multi-region, eventually consistent, nodes adhering to some protocol used for passing around (in essence) a huge scalable, partitioned git repo.

Also this might be complete crazy talk, but that's okay. It's a much better dream than a world where the internet has become full of paywalls and tracking.

</comment><comment><USER44> The author would like to limit the web to markdown?</comment>


Will Everything Stay in New Orleans If Cameras Capture It All? - <AUTHOR> https://www.nytimes.com/2018/01/30/us/new-orleans-security-cameras.html <comment><USER2> Two points that always put a dent on "surveillance in the name of safety"

1\. Make all the camera feeds accessible to the public. Afterall, shouldn't more eyes help a place be safe?

2\. Install cameras around Police HQs. Don't they want to be safe too?

Of course those who advocate surveillance in the same of safety are also the first ones to ensure they are never on camera themselves...

<comment><USER3> > 2\. Install cameras around Police HQs. Don't they want to be safe too?

This is one of the things that makes me laugh with annoyance at the signs at, say, Customs and Immigration when entering the U.S., or at the entrances to courthouses, or (formerly) around airport screening areas. "No pictures or video are permitted. Cell phone use prohibited."

What, precisely, is going on that shouldn't be photographed? If one camera in the ceiling is good, aren't 931 cameras all that much better?

As always, the safety of the enterprise is paramount.

<comment> tj-teej Everyone who works in XX-Sec will tell you that every system has weaknesses, in this case I think that it is those weaknesses which shouldn't be photographed.

I think the logic is that the bad guys would use the pictures to identify the weaknesses and evade the screenings.

Now, whether the point of Airline security really is to catch the bad guys is a whole different story...

<comment><USER4> If pictures can identify weaknesses, can't "The Bad Guys" just go there themselves, or send their lackies.

<comment><USER5> Send someone important: "You got here for your stay in ADX Florence... and we didn't even have to extradite, torture, or rendition you to get you here! What a guy!"

Send someone not important: "You know what? I'm glad I forgot how to light my liquid-based shoe bombs that need exactly 101ml of fluid to blow a fatal hole in a plane. The inflight meal was much better than I thought it would be. I mean it wasn't great but it was not horrible either. When I got off the plane, There were infidels and uhhh there was security and umm stuff. I didn't take any pictures because there was a sign that said I shouldn't. It was easy to find which suitcase was mine because of the rainbow colored strap my niece chose for me to put on it. What do you think of the mouse ears I got you from Disneyland? ...boss?"

</comment></comment></comment></comment></comment><comment><USER6> > Kelby Reed, who lives in the city's Ninth Ward, said he favored expanding > the presence of security cameras in New Orleans to deter crime.

This isn't about deterring crime, it's about catching criminals. Which is not the same thing. I wish departments would be more upfront about this.

There's no statistical link between cameras and crime prevention [1].

[1][https://cityroom.blogs.nytimes.com/2009/03/03/study- question...](https://cityroom.blogs.nytimes.com/2009/03/03/study-questions- whether-cameras-cut-crime/)

<comment><USER7> Robberies at British banks have fallen by over 90% in last 2 decades and one of the reasons quoted are CCTVs. Of course, cameras by themselves are not enough, they can only be a part of the solution, together with the police and community efforts.

<comment><USER8> Meanwhile, credit/debit card use has soared and cash reserves have declined. But that can't have anything to do with it, think of the children!

</comment></comment></comment><comment><USER9> _" The broad public safety plan announced last year, which included an early version of the camera plan, discussed taking steps to "reduce the culture of permissiveness" in New Orleans."_

That already happened to San Francisco. Coming next, the San Francisco Homeless Tracking System.[1]

[1] [http://www.sfchronicle.com/bayarea/article/SF-s-ambitious- ho...](http://www.sfchronicle.com/bayarea/article/SF-s-ambitious-homeless- strategy-seeks-sharp-12245176.php)

</comment><comment><USER10> Mostly OT: Isn't the phrase "What happens in X stays in X" more closely associated with Las Vegas, which must be one of the most heavily surveilled cities in America? [https://lasvegassun.com/youre-being- watched/](https://lasvegassun.com/youre-being-watched/)

<comment><USER11> I always interpreted the tag line to be more about the social acceptance of what would be considered deviant behavior elsewhere.

<comment><USER12> Yes. The implication is come to Vegas and do wild stuff with no one at home the wiser. The contra is a favorite t-shirt I've seen at the airport: What happens in Vegas stays on Facebook and YouTube forever :-)

</comment></comment></comment><comment><USER13> Can we fix the title? It should be "Will 1,500 Street Cameras Be a Wet Blanket in New Orleans?"

The current title makes no sense.

<comment><AUTHOR> The NYT changed the title since I posted it, I suspect they agree with your assessment.

</comment></comment><comment><USER14> I read accounts of people responding with hostility to google glass (there was a time when it was considered bad etiquette to take someone's picture without asking, and plenty of people feel this way now. I honestly don't really like being recorded). But the technology to embed this in a way that is undetectable will almost certainly be developed before long, and could all be uploaded to the cloud.

Once it's there, I'm pretty sure law enforcement will use various machine learning approaches to process and scan vast amounts of uploaded visual and audio imagery in cloud storage (I believe this already happens on a smaller scale). As for New Orleans? In my opinion, this very likely to happen with or without the cameras.

</comment><comment><USER15> If it's done with respect to people's privacy and able to reduce/deter crime, why not?

<comment><USER16> How can you be sure they will respect privacy? That's the $10,000 question here.

<comment><USER17> No one can be sure, but if they only place these cameras in public locations and have them facing public areas, then there should be no expectation of privacy to begin with.

If they have them facing private areas and use them to record those privately owned areas, then that's another issue.

<comment><USER18> There's a vast difference between permanent blanket surveillance of a public location and incidental witnessing of events in a public location.

It's like the availability of mugshots. Decades ago, they were also public documents, so in that sense nothing has changed. But now that they are so much more accessible, vile businesses now retrieve mugshots in bulk and publish them online in order to shake down people who have been arrested.

</comment></comment></comment></comment><comment><USER19> I live and work in New Orleans. I don't live in the best part of town.

Bad stuff happens here like everywhere but I very very rarely fear for my safety.

This is a definite case of 'control/corruption in the name of safety'.

How do we stop it?

<comment><USER20> There are community groups organizing to oppose the expansion of the security state in New Orleans, including but not limited to MaCCNO: [https://maccno.com/join-the-opposition-to-new- orleans-40-mil...](https://maccno.com/join-the-opposition-to-new- orleans-40-million-security-plan/)

<comment><USER19> Thank you!

</comment></comment></comment><comment><USER21> Rich white people tend to ask the question, "How can we stop the crime?"

Poor black people tend to ask the question, "Why do they keep us at the end of our rope?"

And never the twain shall meet.

</comment><comment><USER22> Don't worry, only some of the cameras are maintained and operational, if we can trust a 3rd season plot-line from the fictional show Treme.

<comment><USER23> I can say for certain that a lot of the speeding and red light cameras are _definitely_ in working order.

<comment><USER24> Profit centers always work.</comment></comment></comment>