Hacker Newsnew | past | comments | ask | show | jobs | submit | FpUser's commentslogin

I've never felt like automating my days, be it work, hobby or whatever. Programming sure, I do use AI under supervision

>"All other electronic instruments, with the one exception being the Theramin, have a fundamental problem with human expression. There is an unsolvable disconnect between what the performer's actions and their audience."

Look at Roli Seaboard, it has insane amount degrees of freedom / expression

https://youtu.be/2fQbtp2BgY4?si=S52A-22A3GlXPajU

past the middle starts solo


Ability to make certain kind of software is totally strategic for countries to be independent. Completely relying on some other 3rd party is truly stupid.

>" Sometimes when we think we are 'multitasking,' we're just looking for ways to avoid the problem."

Which can be correct course of action. If I stuck trying to figure out how to solve some hard problem it is very good ide to switch for a while and magically the solution comes back later on since brain still manages to do something in background. Alternatively if I have to do whole lot of monotonous non rewarding work for whatever reason I would go nuts if I try to finish it in one step (considering it is long enough)


>"just how hard doing this stuff is in C/C++ without creating a lot of dead locks, crash bugs, and security issues"

In my opinion this is probably problem for novice. Or people who only know how to program inside very limited and restricting environment. I write multithreaded business backends in modern C++ that accept outside http requests for processing, do some heavy math lifting. Some requests that expected to take short time are processed immediately, some long running one are going to a separate thread pools which also manage throttling of background tasks etc. etc.

I did not find it any particularly hard. All my "dangerous" stuff is centralized, debugged to death years ago and used and reused across multiple products. Stuff runs for years and years without single hick-up. To me it is a non issue.

I do realize that the situation is much tougher for those who write OS kernels but this is very specialized skill and they would know better what to do.


A key difference is that it sounds like you need to create and otherwise interact with that sort of code on a regular basis.

Most devs spend most of their time, all of it even, on tasks that are either naturally sequential or don't benefit from threading enough over the safer option of multiple independent processes, so when they do come across a problem that is inherently parallelizable and needs the highest performance it is not a familiar situation for them. Familiarity can make some rather complex processes feel simple.

The same can be said for event loop driven concurrency, for those who don't work that way often the collection of potential race conditions there can feel daunting so they appreciate their chosen platform holding their hand a bit.


>"holding their hand a bit"

Holding hand is useful until it is not. It often has big trade offs.


Probably not unless using Rust present some particular challenge for this type of project. But having eaten this proverbial apple they would probably use AI more and more assuming they have a budget and in this case being less rich than C++ might not mean much for productivity

I think we've come to the point when it should be the opposite for any new code, something in line of: "done without AI". Bein an old fart working in software development I have many friends working as very senior developers. Every single one of them including yours truly uses AI.

I use AI more and more. Goes like create me classes A,B,C with such and such descriptive names, take this state machine / flowchart description to understand the flow and use this particular sets of helpers declared in modules XYZ

I then test the code and then go over and look at any un-optimal and other patterns I prefer not to have and asking to change those.

After couple of iterations code usually shines. I also cross check final results against various LLMs just in case


Below is one of the comments poster to original article, reading it makes me think that most of the whole article has been regurgitated by some AI:

>"This misleading article contains numerous factual errors regarding automotive lidar. Here are the most glaring:

There are multiple manufacturers, including Hesai, that use mechanical means for at least one scan axis and are already sold for a fraction of the "$10k - $20k" price noted by the author. Luminar itself built this class of scanners before going bankrupt.

Per Microvision's own website, the Movia-S does not use a phased array and also does not have a range anywhere near 200m.

Velodyne and Luminar do not even exist as companies anymore. Both have gone bankrupt and been acquired by competitors."


>"to build win32 you have to pay developer fee to Microsoft"

Not really, you can self sign but your native application will be met with a system prompt trying to scare user away. This is maddening of course and I wish MS, Apple, whatever others will die just for this thing alone. You fuckers leveraged huge support from developers writing to you platform but not, it is of course not enough for you vultures, now let's rip money from the hands that fed you.


Keep blasting, I do not care. I like OnyOffice. It feels very light and fast and handles my very limited and light usage with grace. LibreOffece in my opinion does not come close by feel.

I also use it, but I would not call it light and fast.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: