gonational

Joined 9 years ago

Karma
756
Submissions
490
Member since
May 13
License plate # 35102
View on Hacker News

Recent submissions

Comment · 29 days ago
Use genetic engineering to extinct a species... what could go wrong?

Not to mention the many species of, e.g., birds, etc., that rely either heavily, or almost entirely, on mosquitoes, as a food source. One does not simply eradicate an entire species, through genetic sorcery, for the entire planet, without causing negative side effects.

This is just like cloud seeding. A few powerful idiots ruin it for everyone else, in the service of accomplishing a specific goal. We are likely experiencing major changes in the regional climates, as a result of cloud seeding. For example, right here in Idaho we are stealing water from clouds floating overhead, through a cloud seeding program primarily driven by Idaho Power. Do I benefit from this? Of course. We use the irrigation water and benefit from the cheap electricity rates. At what expense? Who knows. Somewhere east of us is likely getting royally screwed. As long as we have what we need here, though, who cares about anybody else or the rest of the planet's ecosystem, right?

The hilarious part, to me, is the fact that those who get excited by this idea (obliteration of entire species through genetic engineering) are the selfsame supposed champions of the climate when it comes to "GlObAl WaRmInG", asking for us to send our money to the Guberment to fix the problem. I guess it's not too surprising, since these people don't think for themselves; they are simply following with the TV told them to think.

Comment · 5 months ago
$400,000,000,000 revenue, 2025.

$650 million is a rounding error.

Comment · 5 months ago
It's not that you can't "build a sane architecture" as much as it is difficult to justify the time spent to do this when you can "bang out features" in 10 minutes that would take days to do manually. It's about the economics of code generation. When inventing structure and typing it out as code takes time, thinking deeply about architecture first makes sense. There is another factor, as well: "thinking deeply about the architecture" involves experimentation. You might go down a particular path while coding, and then realize some limitations and/or new ideas, etc. You ultimately craft something that will work well and play well with future code, and which may be easily understood. If somebody stops by your desk and says, "you finish that <3 day feature you were just assigned 2 hours ago> yet?", that'll be the last time you think deeply about anything at work.

Rather than arguing about the specifics, it's easier to point to numerous concrete examples, such as a fairly simple system - which should be easy to implement in 8-15k lines of code, depending on certain choices (I've been writing code long enough to estimate this relatively accurately) - being still-incomplete while approaching 150k lines. These kinds of atrocities are usually economically infeasible in hand-written code, for 2 reasons: 1) the cost to produce that much code is very high, and 2) the cost of maintaining that much code is insurmountable.

I guess you could say that AI is great at generating code that only AI can understand and maintain.

Comment · 7 months ago
You are absolutely not alone, brother (or sister). In the past few years when a lot of the millennial generation started getting their first jobs, the shiny object syndrome took over and most everything being made now is a distributed monolith pile of spaghetti code trash.

There are endless tools available, and quick internet dopamine feedback loops, but almost no wisdom.

Give it a few more years and more inflation, and the remaining 35% of millennials will get out there to find their first jobs, and then the impact will be even worse.

Comment · 8 months ago
This!

It absolutely boggles my mind that nothing else exists to fill this spot. Fly and others offer varying degrees of easier-than-AWS hosting, but nobody offers true PaaS like Heroku, IMHO.

Comment · 8 months ago
It's honestly just an example of ego and coping. These people are trading temporary gains in pseudo-productivity for training their replacements and atrophying their skills.

The truth of the matter is that the people who will choose to partake already weren't thinking; otherwise they wouldn't have chosen. This is the same with every bubble or major revolutionary thing that ends up having negative effects in the long run. GLP-1 is another great example of one that is still on the upward arc.

Sheep will always be sheep, and, in my opinion, this is the reason for the changes in hiring and the large scale encouragement of folks that obviously are not smart enough for this career to suddenly join in over the past 10 years.

Comment · 9 months ago
Pardon my huge voice-to-text comment ^
Comment · 9 months ago
I've had the misfortune of working in FastAPI a number of times, and, as somebody who has been using Django since 2008, Django developers have no idea how spoiled they are to have such a tremendous framework.

Django does not provide magic, but it's ORM is like pure sorcery compared to the garbage out there (SQLModel, etc.).

Django provides the necessary tools to build terrific software. However, it does not prescribe extra extraordinarily high-level architectural guidance, so it leaves that up to you. For example, if you are building an app that will have a main UI for users to login, a backend UI for managers to view reports, an API for consumption by outside developers, Django doesn't provide some kind of automatic recommended pattern for structuring your app to support all this. However, it provides the exact ingredients you need to do this on your own. In the example a gave, you would simply structure your directories to reflect the various UI / inputs modalities, and then point a path to each section (urls.py). If you want to host your API as a separate service, you just define a WSGI/ASGI app and pointed to a separate urls.py, then start that container using that WSGI/ASGI app, simple as that. Django does not have any kind of magical mono effect structure to it. It is just a collection of unbelievably useful and clean and simple API that you can use to compose software at least 5x more quickly then you can with e.g., FastAPI. I'm in the second team I've been in that is using FastAPI, and it is uncomfortably slow, you wouldn't even believe it. With FastAPI or other API/micro frameworks, I think the perception is that "it's just python" as if Django is something else, and so people start off app.py and they "see now I can start from this fresh canvas", and then they learn after spinning their wheels for two years that having a solid ORM is actually important, having migrations that are always correct and automatically generated is important, having an admin interface for viewing, creating, managing local/testing data while debugging things, etc. is important, having an ORM that lets you do aggregation and annotation so easily that you find yourself wanting to make reports just as an excuse to use these features, is important, having a template system that lets you generate dynamic pages without having to set up a full SPA for every little interface that you want to make allows you to make a quick prototype or even a permanent UI of some kind without having to involve a team of front end developers who will then begin to dictate your entire backend architecture through their litany of ever changing API endpoint requirements. Speaking of, the common pattern that I have noticed with SPA/API based develop is that the front end wants to be large and in charge, until it comes time to validate data inputs or have to do anything with data that requires looking at it holistically (for example, given a list of orders, if there are any orders that have items that are backordered, provide a warning at the top of the page… SPA developers completely crushed by this requirement, now the backend has to add additional information via the end point called "are there backorder items", etc.). So you end up with this hodgepodge of mess, instead of creating a prototype of your interface and then coming back and deciding which things need to be "reactive", and either shoehorning those things in or rewriting your UI because it's absolutely necessary.

This has become quite the rant, but as somebody who has worked on software for nearly 20 years and can hand write HTML, CSS, JavaScript, use Svelte / React, Python, Django, SQL, etc., I've learned a LOT and seen a lot and I can tell you absolute certainty that choosing Django for a new project is the absolute most effective choice you can make on your path to success.

Comment · 9 months ago
This is the most correct comment I've ever come across.
Comment · 10 months ago
Comment · 10 months ago
IMHO, the "new generation" of designers is the problem. Same goes for the "new generation" of developers. Want to make a basic HTML page with a contact form? Better get React + 300 dependencies, require the backend to provide a REST endpoint... fast forward six months...

Why has this happened? Everything is too easy. You used to have to have pretty good intelligence to break into UI design and software development. Now, anyone can do it with 30 minutes of "e-learning", and, therefore, the average IQ of a UI designer/or software engineer has decreased, dramatically.

Comment · 10 months ago
Yeah it's crazy, people use Django and they think the things that are making them productive are all these little contribs and built-ins, but the reality is it's the solid foundation that is the ORM. BTW, I discovered after writing my comment that tortoise ORM is essentially Django ORM, but written on asyncpg, making it way faster. So, if you're stuck in some other non-Django framework and would like to use the Django ORM, that's probably your closest bet.
Comment · 11 months ago
Try RQ.
Comment · 11 months ago
I agree, type annotations need work. I just use stubs and then I have some rules to set some of the more common ones to be warnings instead of errors, and then I just deal with the fact that there's gonna be some yellow squiggles.
Comment · 11 months ago
I sometimes think that the direction web development took is like some kind of bad dream that we will wake up from. It's unbelievable to me. The problems we faced before SPAs were things like "great we've got two forms on the same page and this widget on the top right needs to update when a message comes in from the back end… How will we ever solve this", and before anybody could come up with any good patterns google came on the scene with Angular, and ruined the entire direction of the Internet, forever.

TBH I also think that Alpine and HTMX are just as dastardly and disgusting, maybe even worse. I don't know why nobody can figure out a good way to just put in reactive components where you need them. All of the frameworks support that, Svelte seems to be the one that is the least against that, but I still don't see anybody using it that way. Front end developers, which tend to have the least business logic experience, somehow captured the entire SDLC. This is why literally all software is just completely riddled with insufferable bugs, beyond anything anyone in the 90s could have imagined.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton