TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

How much do we bend to the will of our tools?

26 点作者 Teckla超过 5 年前

7 条评论

bediger4000超过 5 年前
I know this article relates to programming, not linguistics, but...<p>I live near a street named &quot;Elati&quot;. Humans pronounce that Uh-lah-tee, all 3 syllables nearly the same emphasis.<p>Google maps calls it Ell-uh-tee, emphasis on the &quot;Ell&quot;.<p>How long before human language bends to the will of Google maps&#x27; pronunciation algorithm.<p>I don&#x27;t think this is good or bad, merely interesting, and I&#x27;d like to know the name linguists have for this phenomenon.
评论 #22237313 未加载
评论 #22238010 未加载
thedirt0115超过 5 年前
&quot;Can we explain the differences in identifier length preferences between language communities by pointing to the availability of reliable auto-complete in one and lack thereof in another?&quot;<p>I&#x27;d have to say &quot;no&quot; to this. What immediately jumped to mind was Java vs Go, where there seems to be a strong preference towards shorter identifiers in Go even though there has basically never been a time when Go did NOT have good autocomplete capabilities.<p>One might argue that Go tends to have shorter identifiers because the authors of a lot of the earliest Go code came from a C background where there wasn&#x27;t autocomplete. But nearly every language has reliable auto-complete these days, so I&#x27;m gonna stick with &quot;no&quot;.
robomartin超过 5 年前
Well, when you have a Sawzall you pretty much let it drive...just pull the trigger and go.<p>Half-joking, of course. Now, that might seem like an off-topic comment but, if you think about it, the analogy might be somewhat reasonable.<p>BTW, I am NOT implying this is a bad thing. And yet I have to thrown in the &quot;With great power comes great responsibility&quot;. I like intelligent tools that help me do my job. I don&#x27;t care about things like --sorry-- the cult of vi&#x2F;vim (text entry speed is irrelevant).<p>My reality is that, as a multi-disciplinary engineer I find myself context switching all the time, from mechanical engineering, to optics, electronics, embedded, FPGA&#x27;s, workstation, mobile and even web. When you context-switch like that the tools can really help you make the switch with less friction. So, yes, when you are changing languages and frameworks with some frequency rather than working in the same ecosystem for years, things like intelligent completion and suggestion, intelligent awareness of libraries and frameworks and a few other features can be massively helpful. This, BTW, is why I like the Jetbrains tools, not only are they excellent and well done, they help with all sorts of intelligence and integrations.<p>But, yes, if you don&#x27;t know what you are doing a Sawzall can cut off your leg.
评论 #22238088 未加载
评论 #22237275 未加载
christiansakai超过 5 年前
Yes I noticed myself doing this and also my colleagues when I used IDE.<p>Now I mostly use vim and I notice myself trying as best as I can to code so that I can understand it with plain text editor. And it shows. I personally keep using vim because of this reason.
pjc50超过 5 年前
Nah, I&#x27;ve seen people write things that horrible long before they had tools to deal with it. People used to write BASIC that looked like this: <a href="https:&#x2F;&#x2F;cdn.arstechnica.net&#x2F;wp-content&#x2F;uploads&#x2F;2012&#x2F;12&#x2F;BASIC-code.jpg" rel="nofollow">https:&#x2F;&#x2F;cdn.arstechnica.net&#x2F;wp-content&#x2F;uploads&#x2F;2012&#x2F;12&#x2F;BASIC...</a><p>Readability is nice, but it&#x27;s a luxury, and a subjective one.
fhood超过 5 年前
I don&#x27;t understand. Is it really all that common for developers to auto-format code and not spot check the result?<p>Is using auto-formatting tools particularly widespread? Don&#x27;t most people just format the code to their liking as they write it? Am I completely off base here?
评论 #22236794 未加载
评论 #22237263 未加载
pixelrevision超过 5 年前
The example in the article certainly did not bend to the will of the “code review” tool. The issues had nothing to do with a linter, the author just never went back to consider if it was legible.