>Even quite minor OS updates can cause the tests to fail en masse
I found it didn't even take that. Sometimes indeterminism in the code you wrote or indeterminism in code you can't even control will cause tests to fail en masse.
1,560 karma · joined October 24, 2018
I found it didn't even take that. Sometimes indeterminism in the code you wrote or indeterminism in code you can't even control will cause tests to fail en masse.
It's called capitalism, not "I have an idea-ism" for a reason.
There are some businesses that operate in markets with low barriers to entry but they tend to be A) new and extremely risky or B) hypercompetitive.
Lack of capital. It's called capitalism, not "i have an ideaism" for a reason.
I can. It's people who make blanket statements about static or dynamic typing who can't.
>I guess chasing runtime exceptions during development is an acquired taste.
Much like building software people actually use.
I do find that well crafted integration tests give the best bang for the buck.
>First of all, I doubt it. Second, you just sound rather arrogant.
This was a mirror image response to your condescending assumption that I "just hadn't worked on large enough code bases"
It's a little sad that you didn't have the self awareness to recognize that my feigned arrogance was satirizing yours ;-)
Types are an intrinsic part of ergonomics.
>I'd rather see something else being an ambassador of static types.
I'd be happy to see another language be an "ambassador of static types" provided the tip of the iceberg of 'visible things built in it' doesn't compromise of say, one spam filter and a file converter.
I'm getting pretty tired of hearing about how awesome and productive haskell's type system is for 15 whole years and seeing a whole lot of evidence that it's waaaaaay too unproductive to build anything of use in it.
Rust is a fine ambassador of static types (and has some great usage examples), but rust and python address extremely different non-overlapping markets and rust isn't shy about the fact it makes it fucking hard to compile things in.
With a decent test suite and a bunch of well crafted asserts, it ends up being much quicker. Indeed, for the really subtle broken stuff, pretty much only a decent test suite can catch it.
>Again, it sounds like your projects were still rather young.
Probably just better tested than yours.
In time, you might learn to appreciate this quality but who knows...
>Python on the other hand is often written without any safety
Oh for sure, but I find it easy to start dialing up python's safety from day one of starting on a project (e.g. start writing asserts), no matter how complicated.
Working around java's horrible type system? Less easy.
Because the OP was about python and because python and java are the two languages where I have worked on refactorings of large scale code bases.
I can't help but feel that if you make a hypothesis (e.g. "static typing is naturally better"), you need to be open to examples that disprove this hypothesis.
>And I don't see how your 3 points about the velocity thing are affected by static types..
Static typing usually means a lot of time spent satisfying the compiler. I don't disagree that this can be useful because it catches bugs (although a lot of stuff caught by compilers are not bugs). I disagree that this isn't a cost/benefit trade off that naturally works out.
I inevitably came the exact opposite conclusion. Perhaps because at the start of my career I was trying to do the same thing with Java, and it added overhead and expense without a commensurate payoff in safety.
Frankly, I think velocity is ridiculously underrated:
* Because of the age old "customer doesn't know what they want" issue - hence you throw away a lot of the code that was not fit for purpose.
* Also because the right kind of architecture is only obvious in retrospect - hence you throw away a lot of the code that was not fit for purpose.
* And finally, because the only times in my career where I've had significant success in refactoring a large mission critical codebase it was python and it was because I'd managed to quickly build custom tooling infrastructure (e.g. testing) to support that refactoring.
I do take some issue with python's type system (e.g. the whole truthiness thing), but on the whole it balances safety and velocity in a highly pragmatic manner.
Yet they expect congratulations. Slack's selfish commercial interest is entirely aligned with hiring cheap developers, but, they put out a press release and the atlantic magazine took it up.
I worked with a another charity that did a similar thing (not prisoners, but the underprivileged) and one of the companies we got some of them jobs at did the same thing.
The company got some cheap developers, avoided commission on a recruitment agency and then proceeded to issue a press release patting themselves on the back.
hm, this example they used was my constituency. I walked around for about 15 minutes until I found the entrance because somebody moved the "POLLING STATION" sign against a wall where it was less clearly visible. I wonder if that's related :/
I wouldn't say "100" < "2" really counts, since, alphabetically it makes sense (an equivalent would be "baa" < "c").
They hired 100x as many call center workers as they thought they'd end up needing and sales skyrocketed.
My (largely younger, tech savvy) friends are always slightly shocked to hear this story - because they didn't appreciate having a human guide them.
Types also help document code. Just like tests.
The point is that both are investments and both have different payoff matrices. Sophisticated are often better at preventing obscure logical bugs. They're also good at uncovering obscure not-bugs and preventing code from getting out until the compiler is satisfied. Bad unit tests also do this.
Haskell simply takes longer to write than other languages. Given two developers of equal skill and experience, anyway. I partly attribute the relative paucity of haskell software out there to this.
The advantage of this is that if you end up not wasting too much time "building the wrong thing". Let's say that you took one form of I/O and built massively strict validation in and then realized later that you should have taken an entirely different form of I/O for your subsystem. All that time building in validation on that useless part of code was a pointless waste.
I don't have any stats, but my gut feel is that on average 40% of code can end up being tossed in this way (in some projects it's 100% =).
Prototyping speed is, additionally, not just useful in reducing the cost of building the right kind of code, it's useful in reducing the cost of building the right kind of test (a really underappreciated facet of building mission critical systems).
In my younger years I used to believe that for mission critical systems "building the wrong thing" was somehow less of a problem in code because you could fix requirements and do architecture upfront with some sort of genius architect. Turns out this was wrong.
In practice I find that static typing as done by, say, Java and C#, excels at uncovering very shallow bugs. Its benefit is the most obvious when you do very little automated testing. The tech industry's dirty little secret is that automated testing is done infrequently and badly, so it looks pretty effective.
I find that if you try to compare the cost of building sophisticated tests in a high productivity language (like python) with the cost of writing code in a low productivity/high type safety language like haskell, there's a pretty blurry cost/benefit trade off. If you take out productivity as a factor, haskell looks much better.
Nonetheless, the idea that static types (and, to a lesser extent, formal proofs) are some sort of silver bullet persists. There is no silver bullet.
It's rarely a good idea to use the latest version of Django simply because most projects will be reliant upon 3rd party libraries which will often be slow to catch up to supporting the latest version.
It will also help insofar as site owners will be less inclined to block "EUROPEAN SEARCH INDEX CRAWLER", just as they're less inclined to block google, despite being inclined to block "small time search index".
The creative, non-capital intensive part where having a diverse ecosystem will help the most is building a layer on top of the index to actually find stuff - e.g. a bit like how duckduckgo is built atop bing's index.
there are plenty of tools that support all 3 clouds, but most of those suffer from some sort of impedance mismatch and/or do not fully support the features which those clouds supply.
It damn well does. If everybody else is using AWS it pays to use it too, because:
* The IBM/CYA effect - i.e. "nobody got fired for picking AWS".
* The supply of experienced users - it's easier to hire AWS skills than GCP skills.
Luckily it's dirt cheap to build.
One pretty common case is browsers - an automated test suite might run an exhaustive list of scenarios in chrome successfully while bugs lurk in edge and firefox which were assumed not to be there.