TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Collecting and curating material is good and we should do it more

141 pointsby sdht0over 1 year ago

9 comments

zapharover 1 year ago
I wonder sometimes if this is the cause or effect of the lack of consensus in software engineering. There are so many topics about which the software engineering community is somewhat split. Typechecked or not typechecked, SQL or Nosql, Object Oriented or Functional. The pendulum swings between them over time but no real established consensus get&#x27;s established.<p>Is the lack of consensus why we don&#x27;t have more curated knowledge? Or is the lack of curated knowledge the reason we don&#x27;t have more consensus?
评论 #37623773 未加载
评论 #37623949 未加载
评论 #37624657 未加载
评论 #37624756 未加载
jl6over 1 year ago
&gt; That&#x27;s a whole book on manufacturing snap fits! I said that there&#x27;s nothing like that in software: we talk about specific tools, but never about specific domains. What if we had a book on how to do versioning, or how to make a good plugin system! That&#x27;d go a long way to improving the state of our field.<p>I suspect one key difference between software engineering and physical engineering is that with software, you hit “it depends” sooner. The way you design and build a software system is extremely sensitive to the precise details of the problem you are trying to solve. There aren’t a lot of domains where there is One True Way to do something. The job of the software engineer is perhaps less about building the perfect “snap fit” (although it is at least <i>a bit</i> about that), and more about selecting from the vast array of “snap fits” that exist, and matching them to the specific problem.
评论 #37624964 未加载
评论 #37625398 未加载
评论 #37624628 未加载
评论 #37624818 未加载
jamestimminsover 1 year ago
I&#x27;ve thought about this a lot.<p>I&#x27;d love a book on &quot;Web Authentication Systems&quot; that is a survey of approaches, real world examples, tradeoffs of different frameworks, core principles, etc.
评论 #37634625 未加载
teddyhover 1 year ago
&gt; <i>there&#x27;s nothing like that in software: we talk about specific tools, but never about specific domains. What if we had a book on how to do versioning, or how to make a good plugin system! That&#x27;d go a long way to improving the state of our field.</i><p>There is, at least, a book on writing text editors:<p>&lt;<a href="https:&#x2F;&#x2F;www.finseth.com&#x2F;craft&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.finseth.com&#x2F;craft&#x2F;</a>&gt;
jdouganover 1 year ago
An excellent idea. We could work out a standardized format and build wikis around them. We should come up with a name too. I think &quot;patterns&quot; would be good.
评论 #37630388 未加载
评论 #37628772 未加载
navaneover 1 year ago
Instead of curating it in books, in software it is curated in languages and libraries, which is so much better. All the low level code you never have to write anymore, are the books that the rest of engineering has. Software is so incredibly good at reusing solved problems that you don&#x27;t even see it anymore.
ricklamersover 1 year ago
Great analysis on the value of collecting and curating knowledge, even without synthesizing it into &quot;best practices.&quot; As an AI engineer I collect a lot of resources here, hoping it helps someone <a href="https:&#x2F;&#x2F;codingwithintelligence.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;codingwithintelligence.com&#x2F;</a>
评论 #37628600 未加载
whartungover 1 year ago
One of the problems with this in software is that the concepts can be straightforward, but when you try to translate it into code, the complexity explodes.<p>Case in point: compilers. This is a very well represented topic, both in print and online. But almost inevitably, what you do find in this space are “toy” compilers.<p>Pascal, for example, is a pretty simple language. By design, and by the nature of how Wirth does things. But slogging through even a full boat Pascal compiler is a slog for anyone. And none of the ones I know of offer much, if any, optimization. In fact most have pretty lousy error recovery as well.<p>I honestly don’t recall the state of, or how the original Oberon compiler was presented in the original Project Oberon book. And that’s about as close, I think, as you’ll get to a walk through and discussion of a “production” compiler.<p>Which is what would frustrate this kind of effort in software. Software is hard. The concepts can be straightforward but getting them implemented and a boatload of detail rears it’s ugly head, because while programming and programmers are all about abstractions, computers are all about details.<p>And those details bloat up the code something awful, to the point it’s hard to see the forest for the trees sometimes. How many times have we seen a snippet of code qualified with “but this isn’t production code, so don’t use this”, and, of naturally, half the plant cuts and pastes it into their next live release.<p>Mind there is an excellent example of this in action with Lion’s commentary on Unix v6. Someone sitting over your shoulder as you walk through the code. But v6 is stone knives simple, can you imagine a walk through a modern walk through a modern, production kernel with a qualified docent.<p>There are other examples, Implementation of 4.3 BSD for example, but even it, considering it’s size, is higher level. It’s not the source code.<p>I have a little program I wrote in Java. It’s a GUI wrapper for a 1000 line fractal generator. It wraps the options and the resulting image. But MY code on top of that is 4000 lines. For a GUI! By God, it must be doing SOMETHING! It was certainly more than I anticipated when I started. “How hard can thus be”.<p>I thought there might be value throwing up a YouTube going through it all, to show what happened and why, warts and bad decisions and all.<p>Not because it’s anything special, but it is “done”. It is “only” 4000 lines, so in actuality, rather short. And it’s not a contrived example. It was written to do something, and deal with all the imperfections in me, in the toolkit, and in the “real world” that it operates in.<p>Plus, as I was writing it, writing this “simple” thing, I was always saying “it’s almost done except for...”. So, perhaps there’s value in a commentary about how that manifest in this little thing.
nuancebydefaultover 1 year ago
I find there&#x27;s already too much written about &#x27;good software&#x27;, &#x27;best practices&#x27;, &#x27;design patterns&#x27;, &#x27;refactoring&#x27; etc. These books&#x2F;articles almost try to force sw engineering into an harness as if it was the military.<p>A lot of sw practices and solutions are in the area of &#x27;it depends&#x27;. That is where good (system!) domain knowledge, cooperation and argumentation comes into play.<p>More often than not, discussions are stalled because of ego, stubbernness, &#x27;i know better&#x27;, &#x27;the standard practice says...&#x27; etc.<p>What&#x27;s needed to arrive at good sw is good collaboration. &#x27;I understood we need to implement this or that because the customer needs..., do you agree?&#x27; and &#x27;the current system works like this so i would propose... what do you think?&#x27;<p>For some reason, it is hard to have such fruitful fully interactive, open and iterative discussions, which is a pity.
评论 #37627883 未加载