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.

What else are we getting wrong about programming languages?

61 pointsby theaeolistover 8 years ago

22 comments

nradovover 8 years ago
One big mistake we keep making is drawing a false distinction between static versus dynamic typing and treating it as all or nothing. Type systems should be <i>scalable</i>, in that programmers should be able to specify as much or as little type information as they want. For example, a variable could be declared with any of the following types. 1. A value. 2. A number. 3. A floating point number. 4. A floating point number between 0.0 and 100.0. 5. A floating point number between 0.0 and 100.0, and optimize for runtime performance instead of precision. Etc. That way you could start with something quick and dirty for a prototype and then gradually lock it down through progressive iterations. Ada and Microsoft Visual Basic incorporate some elements of this concept but didn&#x27;t take it far enough.
评论 #12832970 未加载
评论 #12832755 未加载
评论 #12832618 未加载
评论 #12832987 未加载
评论 #12832437 未加载
评论 #12832468 未加载
评论 #12841956 未加载
评论 #12832720 未加载
评论 #12832993 未加载
cbanekover 8 years ago
I feel like what we are getting wrong is throwing the baby out with the bathwater... repeatedly.<p>Engineers love to engineer things. Why do people invent new languages? Sometimes it&#x27;s a company trying to do something new, or something hard in a different language. Other times, it&#x27;s someone who enjoys languages making a new language, thinking they&#x27;ve finally solved all the &quot;hard problems,&quot; where &quot;hard problems&quot; is defined as problems they actually care about.<p>If you&#x27;re not making a programming language, you&#x27;re probably making a DSL or something on top of another programming language, so now you have the fun and quirks of two languages.<p>Instead, what if we had just a few programming languages, and made them more expressive? We&#x27;d avoid problems with language incompatibilities, libraries, and other general impedance mismatches.<p>I chalk this up to a few of factors: 1) Your syntatic sugar is probably not as sweet as you think it is. Many times, people claim something is easier to read or work with when it is merely easier for them, and different for others. This causes confusion for people who aren&#x27;t used to that syntax. Please stop trying to make boring code look interesting. Boring code is the easiest to work with and fix.<p>2) Languages are hard, and working on a language is a lot harder than most people think. Once your &quot;brilliant idea for a new language feature&quot; actually gets implemented, the more it does, the more likely it is to screw something up.<p>To quote Scottie: &quot;The more they overthink the plumbing, the easier it is to stop up the drain.&quot;<p>3) Because of #1 and #2, language development for major languages like python and C++ are slow. People hate slow, and so they&#x27;d rather build something special for themselves, or try some new language, because it&#x27;s more fantastical. If this is a project for fun, go for it. But if this is for a business, people always constantly think some new tool is the silver bullet. What actually happens is you end up hunting bugs up and down your stack, lack robust programming tools, and end up keeping up with breaking changes rather than using that new margarita machine.
评论 #12832363 未加载
评论 #12832291 未加载
lambdasquirrelover 8 years ago
Sometimes, ideas come before their time? How many times has parametric polymorphism been reinvented? Java tried to pretend it wasn&#x27;t important, and then Go.<p>Python isn&#x27;t really typed, which allows it to avoid those kinds of mistakes.<p>Having been a Haskell programmer, I would argue that the type system is beautiful and powerful, but still not powerful enough that it&#x27;s a game changer. And it may never be powerful enough.<p>People forget that the reason we program is to make stuff for other people. Python gets used because it&#x27;s accessible to the people most connected to the real world problems. The primary in my mind is that there is too much risk involved in transitioning from messy languages to cleaner ones.<p>Much of that isn&#x27;t just in the language, but e.g. how easy it is to debug and deploy. So I look forward to things like stacktraces for ghc, and for stack to continue maturing. I look forward to more people being comfortable with the language.<p>That all having been said, it&#x27;s just way too easy to run into the limitsof non-dependently-typed programming in Haskell. So here&#x27;s another thought, what if string type inference is a dead end?
评论 #12832401 未加载
评论 #12832691 未加载
评论 #12833832 未加载
lisperover 8 years ago
My nomination for what we get wrong over and over again: working under the assumption that there is One True Syntax. There isn&#x27;t. Different syntaxes are suitable for different needs.<p>A single language <i>can</i> support multiple syntaxes <i>if</i> the AST is exposed as a first-class construct. This makes it easy to write new syntactic front-ends. Unfortunately, the only language to date that supports this idea is Lisp, which means that this incredibly powerful idea is conflated in most people&#x27;s minds with lots of irritating silly parentheses. (One of the reasons for this conflation is that once you start adopting this mindset the parens become a lot less silly and irritating, but that&#x27;s another story.)<p>I&#x27;m currently working on cryptography code, where algebraic syntax is very convenient. Here&#x27;s an excerpt from some code I&#x27;m currently working on:<p><pre><code> (define-method (point-double (ec elliptic-curve a b c q r) x y) (bb lambda modp(q, (3*x*x + 2*a*x + b)&#x2F;(2*y)) x3 modp(q, lambda*lambda - a - 2*x) y3 modp(q, lambda*(x-x3)-y) (values x3 y3))) (define-method (point-add (ec elliptic-curve a b c q r) x1 y1 x2 y2) (if (and (= x1 x2) (= y1 y2)) (point-double ec x1 y1) (bb lambda modp(q, (y1-y2)&#x2F;(x1-x2)) x3 modp(q, lambda*lambda-a-x1-x2) y3 modp(q, lambda*(x1-x3)-y1) (values x3 y3)))) </code></pre> Notice that it looks like Lisp (and it is Lisp) but there&#x27;s infix code seamlessly embedded. Moreover, the MODP construct automatically converts everything to modular arithmetic operations, so, for example, x&#x2F;y doesn&#x27;t actually divide but instead expands into (* x (modular-inverse y p)). But when I code, all I have to do is copy the mathematical formulas more or less verbatim and my compiler takes care of expanding everything out into calculations that use Montgomery reduction or whatever optimizations I want to provide. This approach also has the advantage that I can test the correctness of my protocols completely independently of the correctness of my optimizations.
评论 #12832588 未加载
评论 #12832995 未加载
评论 #12832702 未加载
评论 #12833585 未加载
glangdaleover 8 years ago
This is a very good article. I do like Yaron Minsky&#x27;s line, dismissing generally programming-student-based studies rather evocatively: &quot;there is no pile of sophomores high enough to prove anything&quot;.<p>That being said, the idea that a programming language is a user interface and might be primarily evaluated like one, rather than a cult object to be venerated, is intriguing. If half the effort that has been put into ever-more-esoteric type theory had been put into serious long-term studies (perhaps with non-sophomore populations?) of usability, we might know rather more and might be able to design better languages. My suspicion is that very few researchers would be willing to follow UI-driven PL research wherever it leads; at best it might skewer some sacred concepts, at worst it might lead to a bunch of inconclusive statistical hints.<p>Far better to stick a bone through your beard and declare your chosen flavor of { functional programming, type theory, OO, logic programming, ... } the winner.
评论 #12832595 未加载
评论 #12835108 未加载
steveklabnikover 8 years ago
Regarding the litte call-out to Rust here, while it&#x27;s true that we have a strong type system, we also aren&#x27;t doing very much _innovative_ work on type systems. And in many regards, we&#x27;re not even that advanced by the standards of Haskell or Idris.<p>The &quot;production-oriented&quot; bit is important as well; we _need_ those features to achieve our goals, the type system features aren&#x27;t just there because we like type systems. And we&#x27;ve resisted doing so; the most classic example being higher kinded types. People have been asking for years, and they would be useful, but there&#x27;s a lot of stuff that would also be useful, and we&#x27;re focusing on them first. We&#x27;re very wary of adding type system features just because we can.
评论 #12834894 未加载
chenglouover 8 years ago
Is there a programming language&#x2F;research area dedicated to the transitioning of one library API to the next?<p>For example, I depend on Foo v1, and would like to upgrade to Foo v2. Currently mainstream languages either use a type system to indicate the upgrade was unsuccessful (can&#x27;t catch everything, and still require the user to patch things), or allow the user to muddle along, knowing things might break subtly but not enough to be &quot;bothersome&quot; (e.g. node ecosystem).<p>So one Foo upgrade is costing O(n) in refactoring cost where n = dependents of Foo. Given enough patience the Foo author could make an adaptor between v1 and v2 to reduce it to O(1) upgrade (inside Foo itself), but this is asking so much that nobody sensibly do it, except for big projects which provide great migration warnings, codemods, bridges, etc.<p>This, combined with, say, plaintext structural sharing&#x2F;diffing between library versions (so that code size doesn&#x27;t blow up if you have 5 transitive dependencies on Foo), might solve two important problems of dependency&#x2F;versioning hell imo, and keep software as fresh as realistically possible.<p>I understand the general version of this is uncomputable, but that&#x27;s my question: is there research on constraining the expressivity of an language just enough to make version upgrade of a library mostly automatable? Here&#x27;s an idea: first-class support for fetching the code of a transition between v1 and v2, half-automated by the language &amp; tools, half community-maintained &amp; uploaded to a dedicated place. Alternatively, push as much as possible to data instead of functions, to make writing transition code (which would simply be massaging data from one form to another) much easier, like GraphQL deprecation strategies (<a href="https:&#x2F;&#x2F;facebook.github.io&#x2F;graphql&#x2F;#sec-Object-Field-deprecation" rel="nofollow">https:&#x2F;&#x2F;facebook.github.io&#x2F;graphql&#x2F;#sec-Object-Field-depreca...</a>)<p>Real-life example: two React.js components written under two different React versions naturally don&#x27;t interoperate. You can&#x27;t include one inside another. Right now you &quot;can&quot;, but this is thanks to sheer human effort from React.js to maintain backward compatibility, so components using React 15 work with components using 14, etc. Same for Java, Windows, and others. The language doesn&#x27;t help you with that at all. Semi&#x2F;fully automated version transition&#x2F;code generation would be a killer language feature.
dancekover 8 years ago
&gt; A couple of years ago I had breakfast with Guido van Rossum -- he almost left the table when I told him I was an academic PL researcher -- and I was quite impressed with the way he dismissed all mathematical aspects of the study of programming languages but was almost exclusively focussed on &quot;soft&quot; aspects of usability such as concrete syntax.<p>I know next to nothing about academic PL research, but this tells me enough. I know that Haskell is an academic language, and it&#x27;s a good language. But then Python is a good language too, and it&#x27;s apparently almost anti-academic!<p>Anyway, the author seems to have good ideas about where programming language research should be directed. Hopefully someone can one day find a great combination of rigor and usability in a language. Until then I&#x27;m left wondering which of the 5-10 good languages that I know I should use for a new project (or whether I should learn X this time).
评论 #12833078 未加载
freddrefover 8 years ago
Each new language seems to provide diminishing returns from the previous ones if you consider only the language constructs. It appears that everything surrounding the language has more of an impact, how easy it is to get started, how big the community is, how good the package management system is, openness of the language ecosystem.<p>Maybe what we need is more automation and support around the language instead of new languages. Building automated compilation, testing, linting infrastructure could be a way to go.
Ivover 8 years ago
Over time, I saw one intriguing idea that any person would reject immediately as they shock the sane mind, but that I thought may be worth a bit more consideration:<p>Moving away from a pure text format. If you think about it, a lot of projects already do that: Android projects and Visual Studio projects often include GUI descriptions. Sure, they are XML, technically a text format, but not designed for direct redaction by a human.<p>It is the thing I have realized when, despite a lot of ideological reservations, I started to like Visual C#: a programming language is linked to the way it is used, to its IDE.<p>I wish language designers would embrace that fact, and not assume that the IDE would be a generic text editor. I think that is holding back a lot of possible designs.
good_gnuover 8 years ago
If anybody wants an example of how programming languages can be designed with an emphasis on empirical evidence over mathematical proof, take a look at <a href="https:&#x2F;&#x2F;quorumlanguage.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;quorumlanguage.com&#x2F;</a>
programminggeekover 8 years ago
Here is one thing we get very wrong. Programming is a communication tool to describe communication systems. If you were to design a tool to design&#x2F;build communication systems, it wouldn&#x27;t look like what we program with.
mannykannotover 8 years ago
Perhaps the dogma that needs to be reexamined is the notion that programming languages are the key to improving productivity. Perhaps the key might be found in teaching programming differently, or in better or different tools.
wmwraggover 8 years ago
I think one of the main things we get wrong is that pretty much any language can be used successfully to write a small to medium sized program, it&#x27;s when a large program is written that things can start to fall apart. Some language features aid large program developement e.g type systems, but can get in the way, or even seem pointless, when writing small programs
yoodenvranxover 8 years ago
&gt; We should worry, for instance, when Python, a language that breaks all academic language design tenets, is one of the most popular languages in the world.<p>Well, Python has a) an extensive runtime library (e.g. batteries included) and b) you type some text in a file and then you can run your program without dealing with any build system. I&#x27;d argue that both of these things might more important for the average programmer than some perfect but esoteric type system.<p>I kinda love the language C++ but I hate dealing with all the hassles surrounding it. Why is it so complicated to include a random C++ library from the internet to my project? Why do i have to redo my build system when I switch platforms? I usually use Python for 99% of my pet projects because it is just so easy to get started. I have some hopes that Rust improves the plumbing situation for low-level programming languages.
评论 #12832535 未加载
Razenganover 8 years ago
&gt; What are we getting very wrong about programming languages?<p>Perhaps it&#x27;s the fact that languages have always had to accommodate the hardware, rather than the other way around.<p>Why don&#x27;t we have CPUs and memory controllers with built-in support for type safety and garbage collection etc. on the silicon yet?
评论 #12833129 未加载
评论 #12834392 未加载
JBiserkovover 8 years ago
&gt;Is any current language 100 times better than FORTRAN for programmer productivity, just as FORTRAN was compared to machine-code programming? Probably not.<p>I beg to differ. A well-designed Lisp, with the power of homoiconity (code-as-data, real macros), immutability by default and a sane model for concurrency. Running on the most optimized virtual machines (JVM, .NET CLR, JavaScript), with the ability to use all of their existing libraries.<p>I&#x27;m talking about Clojure.<p><a href="http:&#x2F;&#x2F;clojure.org" rel="nofollow">http:&#x2F;&#x2F;clojure.org</a><p><a href="http:&#x2F;&#x2F;clojurescript.org" rel="nofollow">http:&#x2F;&#x2F;clojurescript.org</a>
评论 #12832514 未加载
评论 #12834876 未加载
prmphover 8 years ago
I&#x27;m looking forward to an extremely-typed language, where in addition to the usual types, more specific types can be defined with regex expressions, sub-ranges, even function-based rules, etc.<p>Such extra-strong typing would lead to much more robust program and reduce complexity of testing
评论 #12843600 未加载
js8over 8 years ago
&quot;But I know of no scientific studies actually backing up the (sometimes implicit) claim that this types-first methodology leads to better languages, from the point of view programmer productivity.&quot;<p>So here&#x27;s my problem, maybe I am using Haskell wrong, and somebody can give a good answer (FYI - I am big fan of Haskell, but I am still much more efficient in Python).<p>Let&#x27;s say I write a library, I annotate all the functions with types, so I give it a nice API, and then what happens.. I realize I should have used a different type for this parameter in this library. For instance, a type class instead of normal type. But boy, it&#x27;s like everywhere. Or it&#x27;s a third party library and I can&#x27;t really change the type signatures. I just wish sometimes that I could just &quot;forget&quot; the types temporarily and just borrow the existing logic, and then reintroduce different types, type check, done.<p>To be fair, Haskell has potential solution for this type of problem - type inference. But the thing is, once you write the (expected) type signatures into your program (which is sometimes needed to actually help the type inference, and it&#x27;s also useful as a documentation), they are always there, and sometimes, they obstruct.<p>So I guess I wish there was a tool with which I could manage type information in the program in a lot more dynamic way than I currently do. That would, IMHO, close the gap to the dynamic languages.<p>What about making every type into a type class, would it do the trick? But how would the concrete type be specified, then? Would the compiler pick it?<p>(Maybe it&#x27;s obvious, but let me point out the connection of this question to lambda calculus. I can have two functions in typed lambda calculus which are different, because they have different type signatures, but their actual semantics is identical (provided they get arguments of correct type); or in other words, if we convert both into untyped lambda calculus, we get identical functions. So the question is, why cannot we somehow reuse code from the first function, why we have to define the same code twice with different type signature?)
评论 #12833740 未加载
评论 #12832801 未加载
评论 #12836411 未加载
m1sta_over 8 years ago
Consistency, intuitiveness, error rates, task performance - even if we just heard reference to these four more often things might improve.
ClayFergusonover 8 years ago
Non-typesafeness of javascript is a massive disaster. TypeScript changed my life as a software developer by bringing types to javascript.
评论 #12833373 未加载
cndkxjsnfover 8 years ago
Do you want to invest your time worrying about types or actually programming? My issue with building these type-theoretic monstrosities is that now you suddenly have to tackle two problems instead of just one.<p>Just like the underlying machine code is hidden in modern languages, types <i>should</i> be totally abstracted away when programming in a high level language.
评论 #12832227 未加载
评论 #12832415 未加载
评论 #12832636 未加载
评论 #12832267 未加载
评论 #12832278 未加载
评论 #12833003 未加载
评论 #12832443 未加载
评论 #12832263 未加载