Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A lot of people think CS is "learning how to program in xyz."

In fact programming is just a tool used to implement CS ideas and demonstrate their application in the real world.

In my degree we spent maybe the first 6 weeks on actual learnjng-to-program (in turbo pascal.) Then another later on in Scheme. In 3nd year we did C, I don't recall what instruction we had there - maybe a week? Then 2 weeks in 3rd year where we did 10 different languages in 10 days.

Language was considered a distraction from the science part.

No, it's not reading books about swinging hammers. We were learning about physical forces on wood, and by wood, and other construction materials. We learned the difference between a spice rack, the drawer, and the 40-floor building to house the spice rack.

Sure we wielded the hammer like Thor. But the focus was on the hammered not the hammer.



As someone who hasn't learnt CS -the good way-

I'd wager that I'm interested in a niche of CS, mostly the internet, and websites, and apps and what not. So when I tried to learn C and code unix tools I just felt miserable tbh.

Science !== building

I agree langauge and syntax are just distractions from the -building- part.

In software engineering there's infinte hammers and you can build new hammers out of old hammers btw


During my PhD (not in CS) I met a CS PhD who was working on parallel algorithms. At the time I was struggling with large-scale simulations and HPC stuff so I got very interested. I asked him what programming languages he used.

"Oh I don't know how to code. We don't write programs in CS Theory."


I suspect that they could write code, but I don't think this is so outrageous.


This is honestly part of the reason I abhor statements around "AI/ML will make software developers irrelevant in [insert catchy timeframe]"; the complexity in many (if not most) systems is not the coding. The interaction, the boundaries between systems, the agreements between them, and the subtle nuances among; this is where Things Get Hard.

Then there are the requirements gathering that lead us down this road. And the stakeholders that forgot important details. And that one team that has a hard production dependendency on an obscure DB table you only keep around because it simplifies a join somewhere.

Teach students of CS the latter, and they have a much greater opportunity to be successful.


If LLMs keep improving at the current rate and get to the point where they can reduce hallucinating to a reasonable level, I don't see why they couldn't take on the challenge of abstract system architecture. It's still a problem that can be stated in natural language, which they keep getting better at 'understanding' (at least in the sense of giving more coherent answers).


This is a fantastic metaphor. Thanks for this - I’m going to use it myself.




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

Search: