> Benchmarking cutting-edge graph-processing algorithms running on 128-core clusters against a single-threaded 2014 Macbook Pro. The laptop consistently wins, sometimes by an order of magnitude. LOL, this hits close to home. My company had a modeling specific VM set up to run our predictive modeling pipelines. Typical pipeline is about 50,000 to 5 million rows of training data. At best, using an expensive VM, we mana…
Cold Showers
191–200 of 363 posts
Re: Cold Showers
#192Earlier quoted context omitted.
Well, how is this measured? My experience working over 3 decades with large teams also says this is so (static typing does prevent bugs) but that is not science. How do they measure this 'when you go and check'? I am really curious as I don't even understand how people make large systems without static typing and all massively complex systems that I personally have worked with that run for decades transacting billion…
We don't seem to be able to measure it, despite people trying several wacky approaches. Either that means it's hard to measure, or it means the effect is not actually there. Either way, this means that we cannot say that static typing reduces bugs. > all massively complex systems that I personally have worked with that run for decades transacting billions$ etc without flaws are all statically typed Did you try buildi…
Perhaps it's like the LHC. Static typing reduces bugs above a certain project size, but we haven't been able to perform a study at large enough project sizes. Now if only we could get a bunch of governments all over the world on the case...
(only slightly joking)
Re: Cold Showers
#193Earlier quoted context omitted.
Interesting. I wonder what about software development that we do that you can prove scientifically then. Does planning a project mean faster delivery? Does thinking about architecture up front reduce refactors and technical debt. Does estimating lead to faster software development? There is a lot we have to decide without evidence in how we develop software. Maybe we just pick the things that feel right and make us h…
> Does planning a project mean faster delivery? Does that plan include the client changing their mind 10 times before delivering? Or finding out that some approach doesn't work and that pivoting is needed halfway through? Likely depends on how smart the planning is. > Does estimating lead to faster software development? Unlikely, because engineers are then busy ass-pulling useless time figures over and over instead o…
Yes I agree with you. My point is that almost everything we do in management if software teams and architecture decisions is a guess.
We have to carry on regardless and make decisions.
The nuance is what you do, why you do it and is there cultism or cargo cultism to the decisions.
Re: Cold Showers
#194Earlier quoted context omitted.
Clojure is the only dynamic language I’ve ever loved. It is in its own ballpark, really, though maybe Erlang or Elixir would win me over if I spent enough time with them.
I’ve actually been spending the last year with elixir professionally. I’m embracing some of it… I would love to see its pattern matching and annotations come over to clojure, and would make my clojure code even more “correct.” I don’t super fully “get” all of its message passing plumbing, and I don’t like the quality of its library ecosystem. But clojure’s REPL, babashka, and clojure.spec are sorely missed.
For me, after Clojure, I just get annoyed by every other language's special syntax.
Re: Cold Showers
#195Earlier quoted context omitted.
Are you sure all statically typed languages are slower to develop in than comparable dynamic ones? I used to be thoroughly convinced this was true, but 3 things are now making me doubt it: 1) Statically typed languages with inference don’t require time spent writing signatures. 2) I know I’ve spent time chasing down bugs in dynamically typed software that would have been caught by a type checker. 3) I also know I’ve…
> bugs that would have been caught by a type checker Type checking also introduces its own set of additional bugs by the virtue of object incompatibility, that do not exist at all in dynamically typed languages (or are handled correctly every time by the compiler/interpreter automatically). Take as an example exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of…
> Whenever the object definition changes in another piece of the software stack the statically typed parts will crash
You appear to completely misunderstand what static typing means. Runtime crashes due to type mismatches are exactly what static typing prevents.
Re: Cold Showers
#196Earlier quoted context omitted.
I can't speak for all Ruby developers but I found that I could read a pull request from just about anyone I worked with a and find a spot where they hadn't covered a possible nil with a test. And yes, we had coverage checks. A type system can keep you from having to write those tests.
> A type system can keep you from having to write those tests. Because with a proper static lang (hint: not Java, not C#), nil doesn't exist? Right.
They all have nulls but a static lang will warn you that the value can be null.
Re: Cold Showers
#197> Benchmarking cutting-edge graph-processing algorithms running on 128-core clusters against a single-threaded 2014 Macbook Pro. The laptop consistently wins, sometimes by an order of magnitude. LOL, this hits close to home. My company had a modeling specific VM set up to run our predictive modeling pipelines. Typical pipeline is about 50,000 to 5 million rows of training data. At best, using an expensive VM, we mana…
My rule-of-thumb is that if you have less than a terabyte of data, you're better off processing it locally, and even that is pretty conservative. Big data is for when you have problem sets that simply will not fit on a single machine. With 4TB hard drives going for about $60, a lot of problems are better solved by simple algorithms in efficient programming languages on a single box. There are some data sets where you…
Also depends on the complexity of the algorithm (specifically thinking of large neural networks). We have a model that requires 8 A100s for training due to the size of the activations. No way to replicate that on a local machine and have it train successfully in any reasonable time frame.
However the complexity of the algorithm many times scales with the size of the dataset, either the full corpus or the size of individual examples.
Re: Cold Showers
#198> Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." > Shower: Researchers had programmers fix bugs in a codebase, either with all of the identifiers were abbreviated, or where all of the identifiers were full-words. They found no difference in time taken or quality of debugging. That's a very weird take on the statement. The downside of using abbreviations is probably dominated by the…
People nearly always gravitate towards abbreviations in natural language. The more a word is used, the more likely it gets shortened. LA for Los Angeles, Frisco for San Francisco, Vicki for Victoria, Jay for Jason, Dub for George W Bush, Doozy for Duesenberg, and on and on. Why should programming be different?
> Frisco for San Francisco
wait what. I live in SF and everybody just says SF
Re: Cold Showers
#199Earlier quoted context omitted.
I can't speak for all Ruby developers but I found that I could read a pull request from just about anyone I worked with a and find a spot where they hadn't covered a possible nil with a test. And yes, we had coverage checks. A type system can keep you from having to write those tests.
> A type system can keep you from having to write those tests. Because with a proper static lang (hint: not Java, not C#), nil doesn't exist? Right.
Those languages don't have null safety, but plenty of languages do. Rust, Kotlin, Swift, Haskell, etc.
The claim is true: a type system _can_ prevent null-related issues and eliminate the need to account for them in tests. That's not the same as saying every type system does.
Re: Cold Showers
#200Earlier quoted context omitted.
It’s basically self-evident that static analysis reduces bugs. It’s trivial to construct an example of where type information would catch a bug. Unless there is some reason that including type information increases bugs, the existence of a single example where type information catches a bug would prove that overall type information reduces total bug count.
One could argue that dynamically typed code is often shorter, and therefore both easier to reason about, and possessed of fewer bugs on a bugs-per-line basis. Not really keen to push that line of reasoning myself, just helping picture one possible argument.
As a Haskell programmer, this argument does not resonate with me. I find most dynamically typed languages (e.g., JavaScript) verbose compared to what I'm used to. Of course, plenty of statically typed languages are verbose too. But static typing is not a sufficient condition for a language to be verbose.
I associate verbosity with object-oriented programming, whether statically typed or not.