Would be cool if they could quantity the gains in productivity - eg before we put in the static analysis we had x level of software defects, following these improvements we saw a drop to level y. Trying to introduce similar improvements at my current place but it’s a hard sell without data
The coverity paper may be interesting to you: http://delivery.acm.org/10.1145/1650000/1646374/p66-bessey.p...
Static Analysis at Scale: An Instagram Story
21–30 of 36 posts
Re: Static Analysis at Scale: An Instagram Story
#22> Lets say we needed to deprecate a function named ‘fn’ for a better named function called called ‘add’. wondering why they would deprecate fn instead of renaming everywhere with 'add'. I thought that was one of the main big sells of the monolith.
Re: Static Analysis at Scale: An Instagram Story
#23Earlier quoted context omitted.
The coverity paper may be interesting to you: http://delivery.acm.org/10.1145/1650000/1646374/p66-bessey.p...
The link doesn’t work, I’m interested to read it though.
Re: Static Analysis at Scale: An Instagram Story
#24Can someone with (any) experience explain to me why do seemingly perfectly functional websites need change all the time? Is the production version hacked together or what? Why can't websites be coded once and left to run with the rest of the effort being devoted to maintance/adding more servers as the load increases?
I admit that I know almost nothing about how large codebases function (it might being apparent judging by the question)
Re: Static Analysis at Scale: An Instagram Story
#25> we have hundreds of engineers shipping hundreds of commits every day Can someone with (any) experience explain to me why do seemingly perfectly functional websites need change all the time? Is the production version hacked together or what? Why can't websites be coded once and left to run with the rest of the effort being devoted to maintance/adding more servers as the load increases? I admit that I know almost not…
The space where Instagram operates is very competitive, so they need to keep innovating and exploring new ideas to grow the product, increase usage, and improve retention...
Re: Static Analysis at Scale: An Instagram Story
#26There are some languages where types and static analysis are part of the language.
It's paradoxical that we as an industry hold these two things to be both equal and different.
Re: Static Analysis at Scale: An Instagram Story
#27> we have hundreds of engineers shipping hundreds of commits every day Can someone with (any) experience explain to me why do seemingly perfectly functional websites need change all the time? Is the production version hacked together or what? Why can't websites be coded once and left to run with the rest of the effort being devoted to maintance/adding more servers as the load increases? I admit that I know almost not…
Re: Static Analysis at Scale: An Instagram Story
#28It's curious to me that commonly in programmer discussion, we'll say on the one hand that the programming language you use doesn't matter, while on the other hand tout the benefits of adding types and static analysis. There are some languages where types and static analysis are part of the language . It's paradoxical that we as an industry hold these two things to be both equal and different.
Re: Static Analysis at Scale: An Instagram Story
#29The idea is to have a "safe" and "unsafe" Python (ala Rust) according to some guarantees. Proving termination of program is hard, but it is doable if dev time is dedicated to it, and algorithms are well chosen.
That way, some core libraries could be rewritten and give stronger guarantees.
The idea is used in https://github.com/google/starlark-go which is a subset of Python. People who are used with Python can use it to write imperative config files, and the files are guaranteed to not mess with sensible stuff
edit : some starlark design choices explained : https://github.com/bazelbuild/starlark/blob/master/design.md
Re: Static Analysis at Scale: An Instagram Story
#30It's curious to me that commonly in programmer discussion, we'll say on the one hand that the programming language you use doesn't matter, while on the other hand tout the benefits of adding types and static analysis. There are some languages where types and static analysis are part of the language . It's paradoxical that we as an industry hold these two things to be both equal and different.
Citation needed. I recall people saying they prefer the concise syntax and speed of development with interpreted languages that do not force type annotations and others who prefer the runtime speed and compiler warnings in a typed language. I don’t recall anyone saying they are interchangeably equivalent.
- https://www.codementor.io/agustinchiappeberrini/why-the-it-d...
- https://www.quora.com/If-truly-programming-languages-dont-ma...
- https://spin.atomicobject.com/2015/07/15/language-doesnt-mat...
- https://learnpythonthehardway.org/book/advice.html
The idea that programming language does not matter is a pretty commonly-held view.