ddkto (u/ddkto) - Readit News

ddkto commented on Parametric Modeling with Grasshopper baharmon.github.io/basics... · Posted by u/downboots

ddkto · 4 months ago

It’s hard to believe this is the first time I’ve seen Grasshopper on HN!

Just this morning, a colleague showed me a web app for building option exploration that he had vibe coded on Replit that wrapped around existing core logic in a Grasshopper script hosted in RhinoCompute [1].

The combination of visual programming, the tree data structure and Rhino’s geometry engine has made this the de facto standard for parametric design in architecture (sorry, Dynamo…)

[1] https://github.com/mcneel/compute.rhino3d

ddkto commented on Writing Cursor rules with a Cursor rule adithyan.io/blog/writing-... · Posted by u/adithyan_win

ccppurcell · 5 months ago

Question for users of such tools: can't you ask the LLM at the end of the session to choose the most important parts of the context, compress it using your favourite tool, then decompress at the beginning of the next session?

ddkto · 5 months ago

This is basically what the OP is doing - just think of this of the cursor rule as a summary (aka a compression) of the session.

I did something similar for a small vibe-coded app. After a few back and forths to develop the first working version, I asked the LLM summarize the requirements and state of the app so far. I saved that summary into a `description.md` file, and can include it in a fresh conversation.

I was using simonw's llm so adding a new feature or making a change looks like:

`llm -f description.md -f code.py "Instructions for making another change."`

ddkto commented on Representing Graphs in PostgreSQL richard-towers.com/2025/0... · Posted by u/gsky

yonisto · 7 months ago

This time it must be me... Bilbo is not Frodo's father (Frodo is actually Bilbo's first and second cousin, once removed)

ddkto · 7 months ago

Yes, but Bilbo does adopt him to make him his heir

ddkto commented on Apache Iceberg now supports geospatial data types natively wherobots.com/apache-iceb... · Posted by u/Mosarwat

ddkto · 7 months ago

Some more details: https://cloudnativegeo.org/blog/2025/02/geoparquet-2.0-going...

ddkto commented on Orbit Spirograph (2019) redblobgames.com/x/1903-o... · Posted by u/hwayne

ddkto · 7 months ago

I also once got distracted by Spirographs. We got a Spirograph kit for our kids one Christmas, so I spent some time during the holidays writing a python package to draw them. Nothing fancy, just uses python’s built-in turtle graphics.

https://pypi.org/project/spiro/

ddkto commented on Canada's maple syrup reserve hits 16-year low bbc.com/news/world-us-can... · Posted by u/bookofjoe

jajko · a year ago

For a remote outsider - is the divide between quebec and rest of canada not just a language one?

ddkto · a year ago

The short answer is no, it is much more than that!

The long answer involves several hundreds of years of history…

ddkto commented on Canada's maple syrup reserve hits 16-year low bbc.com/news/world-us-can... · Posted by u/bookofjoe

gwern · a year ago

No, it doesn't. Maple syrup is a minor luxury, easily substituted by other things like jam or honey. Consumers are better off with lower average syrup prices, not propped up by a government cartel, even if those prices have somewhat higher variance: when the price is high, people just substitute away and eat less maple syrup, no big deal. (It's not a necessity like air or water or housing.) If the variance is a big deal for various commercial players like IHOP, then they can just deal with producers directly or someone can set up a futures market, like everything else.

ddkto · a year ago

> Maple syrup is a minor luxury, easily substituted by other things like jam or honey.

Speaking as a Canadian, I suppose this is maybe technically true from an economic standpoint, but…we don’t even accept table syrup as a substitute, much less honey or jam.

(and I’ll bet IHOP serves table, not maple, syrup…)

ddkto commented on The decline of hardware knowledge in the era of cloud native compute magesguild.io/the-decline... · Posted by u/thunderbong

IanCal · 2 years ago

> Only in software do we accept engineers having the absolute bare minimum knowledge and skill to complete their specific job.

You can require that your frontend engineer absolutely must have good assembly knowledge but you'll pay more for them and fall behind your competitors. You can require that your DBA knows how to centre text with CSS, but you'll pay more for them and fall behind your competitors. You can require that the people managing the data centre understand the internals of the transformer architecture or that the data scientists fine tuning it understand the power requirements and layout of the nodes and how that applies to the specific data centre, you'll just pay more for someone who understands both.

Everyone requires the bare minimum knowledge to accomplish their job that's pretty much the definition of "require" and "minimum", limited by your definition of someones job.

"software" is such a ludicrously broad topic that you may as well bemoan that the person who specifies the complex mix of your concrete doesn't understand how the HVAC system works because it's all "physical stuff".

> but having a generation of developers unable to do anything outside their chosen layer of abstraction is a sad state of affairs.

Whether it's sad depends if they're better in their narrower field, surely. It's great if we can have a system where the genius at mixing concrete to the required specs doesn't need to know the airflow requirements of the highrise because someone else does, compared to requiring a large group of people who all know everything.

ddkto · 2 years ago

Yeah, the flip side of there being 'less skilled' developers who operate at a higher level of abstraction is that it is easier to train more of them.

In absolute numbers, there are probably more people today who understand the fundamentals of computer hardware then there were 40 years ago, but it's a much smaller percentage of all the computing professionals.

ddkto commented on The decline of hardware knowledge in the era of cloud native compute magesguild.io/the-decline... · Posted by u/thunderbong

readingnews · 2 years ago

While I mostly agree, I think one thing to keep in mind is that we still need people somewhere who know how to do that. e.g. FAANG might have data center people and sysadmins that know the hardware... we (they? not sure) just need to ensure that in the future, we still have _some_ people that posses that knowledge.

I do not think it is requisite that _all_ developers have that knowledge.

ddkto · 2 years ago

Yes, absolutely - skills move from mainstream to niche, but are still required! For example, a much smaller proportion of the population knows how to farm today than 100 years ago, but it's still important :)

(And sometimes these mainstream, practical, everyday skills stick around in funny ways: https://www.hillelwayne.com/post/linked-lists/)

ddkto commented on The decline of hardware knowledge in the era of cloud native compute magesguild.io/the-decline... · Posted by u/thunderbong

dahfizz · 2 years ago

Whether or not this state of affairs is "natural", I do not think it is "good".

Civil engineers still need to understand calculus and how to analyze structural integrity even though they can rely on modern computer modeling to do the heavy lifting.

All engineers are expected to have some requisite level of knowledge and skill. Only in software do we accept engineers having the absolute bare minimum knowledge and skill to complete their specific job.

Not that we shouldn't use modern tools, but having a generation of developers unable to do anything outside their chosen layer of abstraction is a sad state of affairs.

ddkto · 2 years ago

> Not that we shouldn't use modern tools, but having a generation of developers unable to do anything outside their chosen layer of abstraction is a sad state of affairs.

Funnily enough my day job is writing software for structural engineers (and I am a licensed engineer). Your comments are absolutely on point. One of the most important discussions I have with senior engineers is "how will we train tomorrow’s engineers, now that the computer does so much work?"

40 years ago, the junior engineers were the calculators, using methods like moment distribution, portal frame, etc… today the computer does the calculation using the finite element method. Engineers coming straight out of school are plunged right into higher level work right away - the type of work that junior engineers a couple of generations ago might not have seen for 5-10 years.

My first career development discussion with a senior engineer was "Just work for 10-15 years, then you'll know what you need to be a good engineer."

I have discussed this under the theme of Generation Gap (https://www.youtube.com/watch?v=5gqz2AeqkaQ&t=147s, 2:27 - 8:58), and have a similar conclusion to you: what at first appears as a different generational approaches are actually different facets of a well-rounded, senior technical skill set. Maybe the kids are just learning things in a different order than we did?

Pat Gelsinger et al's discussion of the demise of the tall, thin designer is another interesting perspective (https://www.researchgate.net/profile/Avinoam-Kolodny/publica...)