farhanhubble

Hardware is hard and I applaud every effort to make it easier for tinkerers to build atop a platform. I've been away from it for a long time but how does the RPi system stack up in comparison? With all the hats available and the variety of cases, it shouldn't be too difficult to match the aesthetics, power consumption and exploit all the pluggable peripherals. What are the blind spots?

If anyone wants to take a peek into the Unicode codepoint, here's an indispensable tool: https://r12a.github.io/app-conversion/index.html

I started my software career maintaining and forking Unicode parsers. Arabic, Hindi, Chinese and Thai among many other complex languages. It was great fun and it helped me get a deep understanding of how complex writing was and appreciate the beauty of being able to reduce this complexity down to data structures and functions.

Absolutely cool demo. I used to love this feature in SwiftKey. It still works but after their acquisition by Microsoft they've gone downhill. I've since switched to iOS but would love to try Futo out when it's available for iOS

Easily 99 percent on most tasks. As an example, for a Python project with a dozen modules and ~50 files,a simple instruction like "Design a config file backed by Pydantic to store the project's settings. Keep the models modular" sets up nested Pydantic models, moves the settings to sensibly named JSON fields and updates the code to use Pydantic classes everywhere. Takes a few minutes maybe. Manually done the same task would take me half a few hours in the best case and a day in the worst case.

That's indeed a good example.

However I find their claim "I've lead teams of really competent engineers and I can leave them without supervision for months and come back and not feel like throwing away the entire code base." dubious. We all know how much effort it is to keep the quality of even small patches consistent.

Design, architecture, style and refactoring still require significant involvement. Providing only a description and a criteria will likely produce hopelessly messy code, which is also what you get with most corporate dev teams.

That's fair. In all honesty I'm already feeling challenged but given how much time I save I can set aside some time to keep myself sharp. I can learn more languages. Additionally, as pointed out by others, I'm trading coding effort for design and and strategy, which generally control business outcomes a lot more.

Having said that, I won't use AI for production system if I don't understand the programming constructs in enough detail.

I'm in the "haven't written any code in a while" boat ATM. I'd love to see examples of issues that are so big that they warrant reverting to manual coding.

My main issue has been the inconsistent quality across between model releases and the tendency to insert older APIs or documentation, especially with command line tools.

I can understand if the model struggles with a million line monolithic codebase with a decade of cruft but can't think of why it'd be too much of a pain with new codebases.

If you look at Australian IT companies they're management and consultant heavy. Roles like architects, review boards, program managers etc., exceed actual engineering roles. In such a set up it takes forever to get any real work done.

Then Australian real wages have also declined. So there is already low motivation to work beyond the minimum expectation.

Australia also has strong social security, at least until now, and there are plenty of odd jobs due to the real estate and tourism industries, so there is little pressure to survive unless you owe too much credit.

Automation and technology adoption also lags behind. For example, people still wait thirty minutes on a call to get an appointment with a doctor instead of making an online booking.

For all of these reasons productivity has been low and declining. An extra day off work is a strong stimulus for squeezing what gets done into the rest of the days.

In my opinion this is an extreme, just as the work yourself to death culture in India and China is. On a scale of a few decades economies where people worked agressively harder have grown tremendously but at the expense of the long-term wellbeing of the people. Places like Australia that were well off and felt little pressure to compete have sustained good quality of life but at the expense of having no competetitve edge anymore.

Kiselev’s child reader is being treated as a participant in mathematics, not as a recipient of facts.

Not sure how the other makes this claim when the passage he himself cites is just another clever proof in the list of clever things that maths books throw at you:

It is easy to convince oneself that there exist infinitely many prime numbers. Indeed, suppose the contrary, that the number of primes is finite. Then there must exist a greatest prime; let it be a. To refute this assumption, imagine the new number N formed by the rule N = (2·3·5·7···a) + 1, that is, the product of all the primes up to a, plus one… The first term is divisible by every number in the list 2, 3, 5, …, a, while the second (the unit) is not divisible by any of them. Hence there is no greatest prime, and so the sequence of primes is infinite.

Letov should name it Motepad++, clearly mention that it's a fork and move on.

I wish someone had told me how common this was back when I worked myself to death fixing every UI abnormality that no one except some misincentivized testers used to report at my first job. At the time I thought it was dishonest to say something was irreproducible and it'd be beneath me to patch an issue knowing it'll sprout ten others.

I'm proud of fixing everything properly but I won't repeat it ever unless the company actually has that high a bar across the board.

The cost has always been the sum of:

1. The time spent to think and iteratively understand what you want to build 2. The time spent to spell out how you want to build it

The cost for #2 is nearly zero now. The cost for #1 too is slashed substantially because instead of thinking in abstract terms or writing tests you can build a version of the thing and then ground your reasoning in that implementation and iterate until you attain the right functionality.

However, once that thing is complex enough you still need to burn time on identifying the boundaries of the various components and their interplay. There is no gain from building "a browser" and then iterating on the whole thing until it becomes "the browser". You'll be up against combinatorial complexity. You can perhaps deal with that complexity if you have a way to validate every tiny detail, which some are doing very well in porting software for example.

There could be many plausible explanations.

1. The model's default world model and priors diverge from ours. It may assume that you have another car at the wash and that's why you ask the question to begin with.

2. Language models do not really understand how space, time and other concepts from the real-world work

3. LLM's attention mechanism is also prone to getting tricked as in humans

I haven't used it in a while but RedHat used to feel quite a bit like Windows.

Similar questions trick humans all the time. The information is incomplete (where is the car?) and the question seems mundane, so we're tempted to answer it without a second thought. On the other hand, this could be the "no real world model" chasm that some suggest agents cannot cross.

I use Obsidian to record decisions, plan every day and take detailed notes. Very handy for recalling the nitty gritty for future reference be it performance reviews, writing blogs or updating my resume.

I used to interview mentors for a big EdTech company and met some of the smartest and most humble engineers who were all from Kenya.

If the two are indeed "Linked", I see a case for users-first browsers to show system metrics right along the page.

So the root cause was the model's indisposition to calling the skills. That seems contrary to what we see with function calling. Models call functions quite reliably most of the time. This is more likely because of the instructions not being clear about what skills are, as this snippet, albeit in isolation, seems to suggest:

Before writing code, first explore the project structure, then invoke the nextjs-doc skill for documentation.

Before writing code, first explore the project structure, then invoke the nextjs-doc skill for documentation.

Does the model even understand what this line even means?

I get excited every time I see a "Differentiable X" library, but this one had me the most excited! Seeing the methane molecule acquire its geometry is so cool. Can it work with more complex molecules like small amino acids?

I use Tailwind for connecting dev machines across two continents and as a free user I think it's an amazing product. It breaks my heart to see people losing their jobs because there isn't enough revenue.

I can empathize with the founder too because I was kind of in their shoes last year. Had been laid off and nearly exhausted my savings but I was more worried about having to let go of folks I employed.

I find kitchenwork provides good case studies for computational thinking. Thinking about stacking dishes by their sizes leads to a tour of sorting algorithms and datastructures. Thinking about predicting the prices of different preparations that use the same ingredients leads to principal component analysis.

There's also the application of computational methods to cooking.

There's a gut feeling that comes from having gotten your hands dirty enough that tells you if the LLM is being smart or spitting out bullshit.

Ability is a combination of aptitude, skills, persistence, and exposure. More importantly, intention matters and it show up in the quality of your work. If the intention is to cut corners, no one can stop you from doing shoddy work. Number of years and titles do not matter much if the other parameters are low.

Aptitude paves the way for exploration: learning languages, paradigms, modeling techniques, discovering gotchas and so on. Skills follow from practice and practice requires a tough mindset where you don't give up easily.

So many software engineers learn to code just to pass exams and interviews. They claim they have strong logical reasoning. However, they have only been exposed to ideas and patterns from competitive programming rut. They have never even seen code more complex than a few hundred lines. They haven't seen problems being modeled in different languages. They haven't had the regret of building complex software without enough design. They have not had the disappointment of overengineering solutions. They have never reverse-engineered legacy code. They have never single-stepped in a debugger. All they have learned is to make random changes until "It works on my machine".

Yes, software is complex, disposable, ever-changing and often ugly but that is no excuse for keeping it that way.

My ex-boss a principal data scientist wiped out his work laptop. He used to impress everyone with his Howitzer-like typing speed and was not a big believer in version control and backups etc.

Is this Google's answer to OpenAI's browser launch? The first two paragraphs fail to describe what Disco is.

I have always used SwiftKey and Android. This year I switched to Apple because Android was being bloated by Samsung etc. I'm shocked by how horrible Apple keypad is. I also feel like the touch sensitivity of iphone is worse than Samsung phones.

I installed SwiftKey on iPhone too but even it seems sluggish.

Yeah but it also made me think if deep down neural networks are curated random basis vectors, like in random projections.