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.

Language is not important

82 pointsby r4umover 10 years ago

12 comments

protomythover 10 years ago
I read a story in the Telegraph <a href="http://www.telegraph.co.uk/culture/theatre/william-shakespeare/10372964/Shakespeare-read-in-Elizabethan-accent-reveals-puns-jokes-and-rhymes.html" rel="nofollow">http:&#x2F;&#x2F;www.telegraph.co.uk&#x2F;culture&#x2F;theatre&#x2F;william-shakespea...</a> that talked about the original pronunciation of the Early Modern English in Shakespeare&#x27;s plays. How hearing it in the original pronunciation brought out the puns and rhymes.<p>&quot;I will never be able to do Pattern Matching in Java that&#x27;d look at least remotely sane, but in majority of cases I can also live with it.&quot;<p>Many of us have only experienced the Bard in a modern pronunciation and have enjoyed it greatly. We can live with it, but I cannot help but think that I am missing something. It seems very much like what you miss from using the programming language closest to your thoughts and the tools that go with it.
评论 #8717492 未加载
lostcolonyover 10 years ago
I find it interesting to hear people say &#x27;language doesn&#x27;t matter&#x27; (and similar, &#x27;it&#x27;s not important&#x27;), in general (because often the same people then, when asked what language they develop in, turn around and say that they &#x27;use multiple; we always use the right tool for the job&#x27;), but in this article it&#x27;s especially interesting given it&#x27;s right after &quot;and here are the things I learned, and the things that I have not grokked yet in this language&quot;.<p>While there is a certain truth to there being no inherent reason why you can&#x27;t use an idiom or practice learned from one language in another, it&#x27;s incredibly disingenuous to then say the language isn&#x27;t important (and that it&#x27;s only the concepts learned). The language is what encourages you to think in certain ways, and it helps you code along those ways, while making it difficult to code in others.<p>I recently went from having coded in Erlang almost exclusively for two years, to coding something small in Java, and I can&#x27;t even express how irritating I found the experience. A part of it was writing a combination function (i.e., given a collection, generate every combination of elements). In Erlang it was the work of but a moment, and resulted in 3-4 lines, that were incredibly readable. I then attempted to convert it back to Java...and what do you -mean- collections are all destructive?! Ugh, I have to manually copy them out for this to work?! Etc. So much pain. Java got in the way of writing it cleanly, and when I looked for solutions online written in an idiomatically Java way, I found even more verbose solutions, that tended not to be as reusable (involving explicit nested loops rather than recursion, or recursion rewritten with a while loops; i.e., a collection of 5 items would have 5 loops and not be reusable for a collection of 6 items).<p>Quite simply, using a language with idioms from another language, while possible, is often times intensely painful, with a whole new slew of not well known caveats (since most developers in that language aren&#x27;t using it that way), to where if you know you are going to develop a specific way, you will be far better served to use a language that supports it naturally.<p>And his takeaway at the end isn&#x27;t in any way relevant to the title of &quot;Language Is Not Important&quot;.
评论 #8718575 未加载
评论 #8717500 未加载
评论 #8717307 未加载
rdtscover 10 years ago
I think this is a good insight.<p>It is about semantics -- how do you structure your program in a more functional way or how to you use immutable data structures to model your domain, or do you use callbacks, or actors for your concurrency. Object oriented everything was a fad then functional everything is and so on. And while some languages are more opinionated about one way or the other, you can often structure or start to think in terms of different paradigms in most popular languages today.<p>At a higher level then you have to answer the questions of &quot;Why do I want to structure my program with less global state?&quot;. Why does OO work well here?<p>Another point that is important to make I think is that languages are about the library ecosystem as well. There are plenty of cool research languages Alice, Oz, Curry [Haskell-like logic language] and others. But they lack a rich library ecosystem. So you go to build something and you find yourself writing the library ecosystem first. Which is instructive but not if you want to get to your goal of having a product first.<p>Then there is always the issue of syntax. I hear this about Erlang. Syntax is different, but I think that is not the hard part. If typing . instead of ; at the end of expressions is what kills it for you, what do you do with immutable data structures, and separating concurrent units of your code into actors. That is the harder and more interesting part.<p>I like Fred Hebert&#x27;s idea here -- <a href="http://ferd.ca/on-erlang-s-syntax.html" rel="nofollow">http:&#x2F;&#x2F;ferd.ca&#x2F;on-erlang-s-syntax.html</a>.
sramsayover 10 years ago
I&#x27;m big into FP, but I&#x27;ve studied Haskell only lightly. Of all the posts I&#x27;ve read about Haskell, this is without doubt the most intimidating.<p>Clearly, the OP is a quite experienced, skilled programmer, and yet he&#x27;s been at Haskell for <i>years</i> -- taking books on type theory with him to lunch -- but still struggling with the language at some level.<p>I believe very strongly that programming in one paradigm can really change the way you think about another (learning Lisp changed the way I program in most languages, for the better). But it really sounds as if the payoff with Haskell just isn&#x27;t that profound relative to the amount of effort required (unless your real interests lie with abstract algebra or PL research or something like that).<p>I hope this is not coming across as flamebait. I&#x27;m not wondering whether one can profit from studying Haskell; one can presumably profit from studying just about anything in computing. But Haskell really sounds like a very long slog for a relatively small slice of cake.
评论 #8719704 未加载
评论 #8719930 未加载
评论 #8719029 未加载
评论 #8720370 未加载
评论 #8718845 未加载
twelfthnightover 10 years ago
Frankly, I think it is a great post and highlights the important fact that a language itself isn&#x27;t important, it&#x27;s the way the language shapes your problem solving process that matters.<p>However, what&#x27;s missing from this article is the interplay of languages on teams. What makes Python great is that the code won&#x27;t even run if someone on the team doesn&#x27;t use correct white space, forcing teams to write more readable code. Same goes for Haskell, it forces teams to think in reusable, modular ways.
评论 #8717479 未加载
mightybyteover 10 years ago
From the OP:<p>&gt; the tools that you&#x27;re using aren&#x27;t that important.<p>If language is not important, then why aren&#x27;t we writing everything in assembly language? The fact of the matter is that languages and the abstractions they facilitate are very important. If we&#x27;re comparing things like C vs Java or Clojure vs Haskell, the differences might not be very obvious, but they&#x27;re still there. It could be that the types of programs you wrote didn&#x27;t highlight the differences. But when we look at more extreme cases like assembly language, the flaw in the thesis becomes very clear.<p>The problem here is that it&#x27;s hard to resist the temptation to over-generalize. I&#x27;m guilty of this myself. We&#x27;re humans, that&#x27;s how our brains work. But sometimes it can lead us to flawed conclusions.
评论 #8718187 未加载
dlwjover 10 years ago
Here&#x27;s what I personally see:<p>Pencil on Paper vs Vector Pen Tool on Computer. The difference between these tools doesn&#x27;t matter. Neither will teach you about the importance of proportion of characters bodies, or how the illusion of depth can be achieved.<p>Sure making a curve with a pen tool is very hard, and sometimes a very simple thing you can do with a pencil will utterly flummox you with the pen tool but the end result is worth it. The beauty and scalability of the resulting curve is unparalleled.<p><a href="http://www.paulgraham.com/hp.html" rel="nofollow">http:&#x2F;&#x2F;www.paulgraham.com&#x2F;hp.html</a><p>&quot;A programming language is for thinking of programs, not for expressing programs you&#x27;ve already thought of.&quot;
scrrrover 10 years ago
Programming language specialisation is completely overrated. Job listings should probably rather read &quot;Looking for software developer&quot; than &quot;Looking for Rails&#x2F;Python&#x2F;Clojure&#x2F;whatever-developer&quot;<p>A good&#x2F;experienced developer will pick up any language quickly.
评论 #8717318 未加载
评论 #8717245 未加载
评论 #8718339 未加载
评论 #8717153 未加载
评论 #8717293 未加载
rokhayakebeover 10 years ago
Languages are like raw knowledge.<p>1) You just do not know what you do not know, hence you cannot know how that could be beneficial to you.<p>2) Most of the things you know &quot;do not&quot; benefit you immediately.<p>3) The more you know, the more opportunities you have to know more and solve more&#x2F;better.
drostieover 10 years ago
Speaking as someone who&#x27;s done a good bit of Haskell, the type system only provides a syntax which catches certain classes of errors -- it doesn&#x27;t catch them all, and I&#x27;ve only a couple of times been surprised to see &quot;oh, hey, it worked!&quot; the first run through. (Actually it&#x27;s probably one-for-one between Haskell and JS for me, though I guess I&#x27;ve done several times as much work in JS as in Haskell.)<p>The type system, for example, does not help you when you have five Ints and you use the wrong one for an index and the output of the procedure is thereby completely messed up at runtime. It helps to report a lot of other syntactic errors, and can be thought of as automatically providing the first half of a good test suite.<p>To me the real win of the type system is how it gets you breaking down real-world problems into actual code.<p>Programming has inertia. You can choose to either start writing garbage code until something smells right and then build organically around that smell. Totally valid. Or, you can sit and philosophize for a while about what approach you&#x27;re going to take, build up some lower-level primitives that you&#x27;re pretty sure you want, write some high-level overview with stub functions of what the algorithm does, connect the low-level with the high-level, and then grow organically around that. Also totally valid. For the second one, it&#x27;s really nice to have type signatures. For the first, they get in the way.<p>Both approaches for me involve about the same amount of &quot;wasted&quot; time -- this is what I mean by the problem&#x27;s &quot;inertia&quot;. With the first approach, I do throw away dead code at a prodigious rate; and I often find out that I&#x27;ve reimplemented some popular library function which does it faster and better. With the second approach, I find that I either have to waste time redrawing my diagrams in Visio to show to a boss (so that they don&#x27;t think I&#x27;m goofing off just &#x27;cause I&#x27;m not typing). But I do like the tradeoff of repetitive-strain-injury for lots of drawings.<p>I think most of the mystique of Haskell comes from hackers well-versed in the first kind running into the type system as a mental roadblock which had to be overcome, forcing them to learn to plan a bit more, &quot;here is where I&#x2F;O will happen, here are the state variables I need to thread through this walk of the graph&quot;, etc. You can get that anywhere.<p>I really like the syntax for Haskell function-calls, `a f (g 3 + 4)` rather than `a(f)(g(3) + 4)`. I just want to figure out a way to do tensor indices alongside it, so that I could write tutorials in mathematical physics with the same syntax -- something a bit like the Structure and Interpretation of Classical Mechanics did in Lisp.
评论 #8719094 未加载
评论 #8718415 未加载
评论 #8717451 未加载
peraover 10 years ago
There is a funny typo (spell corrector maybe?): it&#x27;s &quot;Homotopy&quot; not &quot;Homeopaty&quot; Type Theory
评论 #8718380 未加载
michaelochurchover 10 years ago
Disagree x100. Language is important. It does matter.<p>It matters the least if you&#x27;re doing a small self-contained project. For small programs, you can use C or you can use Haskell and it doesn&#x27;t make that much of a difference. And, when possible, you should try to write small, modular programs. I like Clojure better than C in general, but I&#x27;d hire a C programmer who got the Unix philosophy over a Scala or Clojure programmer who carried too much Java (big-program methodology) baggage.<p>On large projects or in architectural decisions, it matters a great deal. The codebase will evolve in a different way if you use Clojure than if you use C. There isn&#x27;t an obvious <i>best</i> choice (although I&#x27;d tend to favor Haskell strongly) but it certainly matters for codebase evolution, code quality, quality of developers, and a host of other factors.<p>As for Haskell, static typing is very powerful <i>if you know how to use it</i>. It may be oversold (it&#x27;s not magic pixie dust that prevents bugs) but it <i>can</i> be used to write very correct, reliable code. That said, to do so is a skill (as with writing performant code, whether in Haskell or C++) like any other, and language alone doesn&#x27;t guarantee much.
评论 #8717495 未加载
评论 #8717493 未加载