Rousseau said "mathematical precision has no place in moral calculations," so I was tempted to see how far I could go. Started it during the holidays, but finally came around to putting a bow on it :)
The human still needs to think, of course. But, I can get to my answer or my primary source using a tool faster than a typical search engine. That's a super power, when used right!
The jump in productivity we had with the world wide web and search engines was several orders of magnitude higher than what you have right now with LLMs, yet I don't remember a single person back in the 2000s calling Google "the greatest tool in human history".
Almost sixty years after ELIZA, chatbots seem to still produce a very strong emotional reaction to some folks.
You can do even better if you memorize three numbers: 301, 477, 845. These are the values of 1000log10(n) for n = 2, 3, 7. From these you can quickly get the values for 4 (= 22), 5 (=10/2), 6 (=23), 8 (=222) and 9 (=33).
For your example 1.49 is close to 3 / 2 so the log will be very close 0.477 - 0.301 = 0.176.
This means that your answer is near 8.176 (actual value is 8.173).
This tiny table of logs can also let you answer parlor trick questions like what is the first digit of 2^1000 (the result is very nearly 10^301 but a bit above, so 1 is the leading digit).
1.49 is in between 1.2 and 1.6 and I have memorised log(1.2)=0.1 and log(1.6)=0.2, so I would think log(1.5) is close to 0.17, using sloppy linear interpolation.
That would make log(149,135,151) approximately 8.17. My calculator also says 8.17. Your guess was good!
I have found linear interpolation such an intuitive approximation method that the tradeoff of having to memorise more logarithms is worth it.
Huge fan of minimizing Kolmogorov complexity [1]. There's a balance, but typically if the same behavior can be described in less code, then the simplicity will yield dividends.
There's an article in IEEE software engineering proceedings around the turn of the millennium that said that defect count was closely associated with any complexity measure you wanted - - including lines of code.
I once said "nearly half of the problems are logic errors, nearly half are misused APIs" and got the retort "and another half are from concurrency".
Of course that as up to nearly 150%, which is probably most people's actual bug count...
What bothers me is that some programmers think that writing the code more dense is already better. But I would argue it's not the characters / less lines of code which creates the complexity, but how many logical concepts (?) you utilize to solve the problem.
Using a smaller set of different concepts also helps reducing the cognitive load, even if it leads to more verbosity ("less clever code").
Everything has tradeoffs, but there's value in reducing both line and character counts as well.
For example, nobody ever uses anything other than ijk for loop indices unless the index is particularly meaningful or they've written a deeply nested abomination. Why? It's not just laziness in typing; it gives more relative room for characters that matter. Longer names and patterns are acceptable if you can't make your point clearly enough with few characters, but length isn't the goal; communication is.
It's important to limit lines of code too (and their widths) because if an idea doesn't fit comfortably on your screen then you won't be able to leverage the pattern-recognition parts of your brain to figure out what's going on.
From a different perspective, you know that feeling you get when somebody dumps a 1000-line PR on you (or an excessively long HN comment...)? It's hard to digest because you can't grok the whole thing at once and have to switch to carefully analyzing each component just to even have the context to then give the thing a proper review. If that same PR could be wired together with a few high-level concepts (less code, but more involved baseline knowledge required to understand it), it would be instantly understandable to somebody with the same background.
This is close to what I would have written. It is almost never about actually the line count. Not even SLOC. For example different languages lend themselves to breaking lines to a different degree. In Scheme I almost always write (define name \nl (lambda (arguments) \nl ...)) Did I now waste a line? Of course not. It is still the same number of concepts and basically tokens involved as would be in Python, when I write "def name(arguments):" but Python doesn't lend itself that well to line breaking, because of its (annoying) whitespace sensitivity. Neither does this make code any more or less readable nor does it increase the chance for bugs. Same goes for many other constructs in both languages. Take a "(cond ...)" for example. I will break some lines there, because the language makes it easy, by having everything delimited with parents, while in Python I will have to type additional visual clutter to do the same.
that reminds me that a week ago there was a (now deleted but has a copy of the content available in the comments) post on Reddit where the author claimed they have attempted manipulating/manipulated voting on lmarena in favor of Gemini to tip the scale on Polymarket where on a question like "which AI model will be the best one by $date" (with the outcome decided based on the scoring on lmarena) they have supposedly made O(USD10k).
This agrees with my limited testing so far, but in a different way: o3 being better at coding and objective tasks, with the most recent Flash 2.0-thinking stronger at subjective tasks. Similarly, o3 seems better at shorter output sizes, but drops off, tending to be lazy.
QA Wolf | AI lead / Multiple Roles | Remote (International) | Full-time | https://www.qawolf.com/
QA Wolf gets engineering teams to 80% automated E2E coverage fast, and keeps it there.
We are growing quickly and building the dream team of engineers to develop our test creation, running, and maintenance platform. The stack is Node.js, GraphQL, React, Prisma, Go, and Kubernetes.
We are looking for a master of AI engineering who stays familiar with the latest best practices and knows the trade-offs of different patterns.
You will own problems end-to-end: collect relevant details, spec and scope solution(s), communicate progress, ship and own the results.
You:
- love coding and want to work hard
- are a self-starter, curious, and ship projects undirected
- have a proven track record of delivering challenging technical projects
- have an eye for design and can make good judgement calls with ambiguity
- are an expert in one or more technical areas
- have meaningful contributions to open source projects
ntfy.sh for a wide range of things connected to git hooks or GitHub actions, since I use git for personal things - gives me a second pair of eyes on things asynchronously
