InfinityByTen

I haven't begun doing side projects or projects for self, yet. But I did go down the road of finding out what would be needed to do something I wished existed. It was much easier to explore and understand the components and I might have a decent chance at a prototype.

The alternative to this would have been to ask people around or formulate extensively researched questions for online forums, where I'd expect to get half cryptic answers (and a jibe at my ignorance every now and then) at a pace that I would take years before I had something ready.

I see the point for AI as a prototyping and brainstorming tool. But I doubt we are at a point where I would be comfortable pushing changes to a production environment without giving 3x the effort in reviewing. Since there's a chance of the system hallucinating, I have a genuine fear that it would seem accurate, but what it would do is something really really stupid.

Having used a customer service, I just happen to know that a smarter and a better chat-bot for a bog-standard service request (like a road-side car breakdown) isn't the solution for a better experience.

But now, since a chat bot is cheaper to run, the discussion in the service provider HQ will be about which chat-bot technology to migrate to because user research says it provides for an overall better UX. No one remembers what it is to talk to a human.

This is why I picked so well on the exposition by Terry Tao. It shows how much clarity of thought he has that he understands the importance of notation.

I personally disagree to the premise of this paper.

I think notation that is separated from visualization and ergonomics of the problem has a high cost. Some academics prefer a notation that hides away a lot of the complexity which can potentially result in "Eureka" realizations, wild equivalences and the like. In some cases, however, it can be obfuscating and be prone to introducing errors. Yet, it's a important tool in communicating a train of thought.

In my opinion, having one standard notation for any domain/ closely related domains is quite stifling of creative, artistic or explorative side of reasoning and problem solving.

Also, here's an excellent exposition about notation by none other than Terry Tao https://news.ycombinator.com/item?id=23911903

I'm a full time dev and even having my home assistant breaking every time I think of upgrading it, is annoyance enough. My home lights and what not are down for two hours and I'm mostly installing HA from scratch and recovering from the backup that I've started to take since the last collapse.

A NAS is a way more critical device and I don't want to lose my data or needing to spend 2 weeks recovering data under an anxiety attack because I hastily did one upgrade.

Tells me how little you know about the country. And that's okay. There are several "rich" countries that are also plagued by graft and bureaucracy. And no, they aren't as happy as Economist indices would tell you.

A lot of ways of life in India are sustainable. In fact going the consumerist ways of West is a step in the opposite direction, given what all problems that has created for the planet. I think the motive of the piece is not the nostalgia of repairing, but how living with constraints births sustainability and how we all can learn from it (including India) and in fact foster it in a positive way :)

Or is that not how the markets work?

If you see others as being "insufficiently equipped" to handle nuance, "because it's hard" or "because they are too resistant" is a judgement I prefer not to pass on others.

> "Because if a desire to seek truth isn't there"

Who defines the truth? As much as I understand there is a need to draw a line somewhere, I also believe that everyone has a right to their truth. And that's my truth. I let everyone have their perspective and don't see a need to impose mine or look down upon them if they don't agree to mine, this included :)

I'm pretty sure you'd already know of this, but once you've written your own version, it might help to compare and take notes from a popular, well-established, benchmarked library: https://github.com/serde-rs/json.

8 years on, I'm still in the same map company along with 3-4 others who have joined after or mid-way their PhDs (and some more who didn't bother) and we do routing for hundreds of customers and basically have everything a PhD group has, including Seasonal Seminars on Routing Algorithms.

Finite element Method is not as exciting as AI (I used to think at some point that it would) and Port Hamiltonian Systems is something not a lot of people talk about, except maybe Dr. Volker Mehrmann and his group :)

Academia is not for the faint hearted and a PhD isn't just about research anymore. It's just a low paying job now, sadly. I still say things like "if I ever happen to go back to academia", as if I did a lot there. But I am an academic at heart, just that pursuing a PhD didn't certify it any better or seem to provide more freedom for exploring my passion for studies or a particular topic.

I'm starting to feel that full software modifiable screens are not the "new age" of in-car experience, but a v.01 of highly customizable, highly complicated settings control; a lazy first implementation. What we are seeing with your design is more of the refinement of the concept. So, kudos to you!

I concur with many people that this might still not completely cut for "eyes-free" usage which you need while driving a car. But for a lot of applications, it's a way more premium/refined interface. I'd limit the number of options on the main menu to 5 and already you've reduced the number of buttons from 10 to one knob.

On the note of just using the haptic feedback: did you compare things to the surface dial? I really expected that to gain more "mainstream" traction, but it seems to have fizzled out.

Do you have a good `--help`? Did you catch the common mistakes and return a helpful error message? Did you put reasonable defaults? Do you have enough examples on how to actually use it: not just one running example, but actually one that uses at least _some_ of the options.

Your UX instincts do get tested in this.

The only reason I moved away from subl is that I got access to a big ass machine and I needed to work remotely. The performance of VS code here is so good that often times I forget that the code and terminal is not my local machine.

We can specialize hardware at the chiplet level and at some point, I expect more players and more standards out there that "synchronization" and "compatibilty" would become a bottleneck/burden.

We will go back to monoliths eventually again is my guess.

Kudos to you for identifying that for yourself and trying to distance from it!

A lot of graduate students write their own code and how did they learn to write code? Anything that works from University courses. I was taught C in university as a mechanical engineer. That's why all my python and C++ code was dreadful. I wrote them like I'd write C.

I don't want a test coverage because I want them to write some fancy industry level code. You can look my Master thesis code up on github (hint, it's the same user name) and it's in Python. Hit me up and we can both sit and roast "me from 4 years ago". Scientists who write code as the basis of what they are claiming... computational scientists, statisticians, physicists, chemists and all those people for whom getting the results are because it showed up on their computer screen and they made graphs for them to testify their claim should know how to deliver code that can be read, understood and reviewed. It should not fail on edge cases and give basic results that keep getting verified each time their work goes from "something is working" to a full fledged beast that's going to claim something.

PS: I found (and of course fixed) bugs in my code in both publications on my name before I submitted. I'll be surprised if I was the only one in history to have been through that.

If I were to go back to academia ever again, the one course I am going to take is coding standards and practices for researchers. They should know basics about git, testing, ideally even a review and CI system. Given my experience in how code is handled in academia, I'm very skeptical about the quality of it and I expect to find critical bugs in them if it's written in a non-cs department. It's actually sad that we depend on the code so much for our publications, but how little attention we pay on how to do it properly. My trust went down in academia more and more when I saw how well defined practices were in industry and how it actually helped maintain a reasonable quality of code.

This is the best of the lot.

I think this idea can be refined further and made more and more robust and is a design pattern in the right direction. With more and more percentage of the population heading in coding-friendly direction I see this as a very viable next step.

Eventually all of them call LAPACK AND BLAS Fortran stuff written decades ago. Just the problem definition syntax evolves a little in each package.