[HN Gopher] We need less powerful languages (2015)
       ___________________________________________________________________
        
       We need less powerful languages (2015)
        
       Author : traverseda
       Score  : 12 points
       Date   : 2023-02-01 21:17 UTC (1 hours ago)
        
 (HTM) web link (lukeplant.me.uk)
 (TXT) w3m dump (lukeplant.me.uk)
        
       | Jensson wrote:
       | Most programmers aren't metaprogramming, to them expressiveness
       | isn't a big issue like it is for programmers making frameworks or
       | languages. Making languages less expressive to make the life of
       | framework programmers easier but at the cost of all the other
       | programmers isn't a good trade-off most of the time.
        
         | nine_k wrote:
         | No lack of powerful tools on a language is not limited to
         | library authors.
         | 
         | If authors can not use powerful tools, they cannot create
         | powerful libraries for other developers to use. Everybody is
         | then pushed down to the low expressiveness level. Case in
         | point: Golang until recently, Java before version 5. Copy-paste
         | programming is as prone to bugs as stringly-typed programming.
         | 
         | If there needs to be a strict separation between powerful tools
         | and easy tools, using two different languages works well
         | enough. Many game engines allow level designers write small Lua
         | scripts, for instance. Or the whole Visual Basic thing which
         | allows to glue together powerful COM components. Also, nearly
         | every templating language allows for simple data manipulation
         | (iteration, filters) while not being Turing-complete.
         | 
         | (That works until the users of the simple glue language require
         | enough features for the glue language to become a principal
         | tools for developing increasingly complex things, and we're in
         | square one. Could have started with a proper language...)
        
       | EGreg wrote:
       | Yes! I liked the original C because of that. So did Linus:
       | https://www.youtube.com/watch?v=CYvJPra7Ebk
       | 
       | I remember this great talk Growing a Language by Guy Steele,
       | totally on point, about Java... I liked Java:
       | https://www.youtube.com/watch?v=_ahvzDzKdB0
       | 
       | I even liked the original C++ when it came out, and used it
       | (although needing to do >> > was a bit silly). But then it jumped
       | the shark with C++0x and thereafter. Concepts. Lamdas. Time
       | travel. Quantum mechanics. Even Bjarne Stroustrup quit and is
       | like "whaaa"
       | 
       | In this interview with Dennis Ritchie, James Gosling, Bjarne
       | Stourstrup, the latter is the most verbose. And it shows in the
       | C++ features hehe.
       | 
       | When everyone knows the 10 features the language has, teams can
       | work together without a language lawyer and tricky "look ma no
       | hands" code
       | 
       | This is what makes games like Chess great, as opposed to, say, Yu
       | Gi Oh: https://www.youtube.com/watch?v=Wr13DYngSqE&t=4m30s
        
       | nine_k wrote:
       | We already have less powerful languages, like C. The results are
       | underwhelming. We need powerful languages with the power
       | _harnessed_ and thus safer to use.
       | 
       | It's like saying that we only need chisels and knives instead of
       | power tools. I'd say we need power tools with proper safety
       | features, and thoughtfully built to make them efficient to use.
       | 
       | The particular case of Python is exactly about the lack of
       | harnessing. The same reasons would apply to Perl even more, and
       | equally to Smalltalk or Ruby, etc; cleanliness of the design is
       | not the point. Any of these languages is basically play-doh. You
       | can build anything from it. It will not be very strong, and it's
       | a bit hard to make it into a precise shape. But it's supremely
       | easy to quickly prototype anything in such a language. When you
       | don' have a clear plan, constantly experiment in a REPL, and keep
       | reworking your design several times a week, nothing beats a
       | highly pliable, highly dynamic language like Python.
       | 
       | Then, of course, you have to ship it, and can't afford rewriting
       | it.
       | 
       | There are hyper-powerful languages like C++ and Rust. They are
       | much harder to wield, and C++ famously does away with many safety
       | features for the sake of ultimate flexibility, while Rust goes to
       | great lengths to ensure safety _and_ efficiency at the same time.
       | Rapid prototyping in them is not easy even for top experts.
       | 
       | There are relatively fine middle-ground languages, to my mind:
       | say, Kotlin (or even plain modern Java), or Ocaml (maybe using
       | the Reason syntax), and even Typescript where you can increase
       | strictness gradually while allowing areas in the codebase still
       | in magma state.
       | 
       | But Python, due to its very friendly and human-readabale syntax,
       | won a lot of mindshare by being easy for a beginner, and also by
       | having a nice set of very important libraries (many not written
       | in Python). So we'll see a lot of software that could benefit
       | from being written in a less play-doh-like language, but were
       | started in Python, and will not be rewritten.
       | 
       | Python specifically tries to grow some safety / stability
       | harness, in the form of optional typing and mypy, protocols, etc.
       | It's better than nothing, but it's still far from allowing to
       | write bulletproof code effortlessly.
        
         | shpongled wrote:
         | Personally, I find rapid prototyping much faster in Rust than
         | Python, and I don't think I'm a "top expert".
        
           | nine_k wrote:
           | Can you write a function in a REPL and run it instantly? Can
           | you easily inspect intermediate results?
           | 
           | I this regard I love Haskell's REPL mode, it's really
           | productive for prototyping. It has a worse discoverability /
           | autocompletion story than Python REPL though.
        
       ___________________________________________________________________
       (page generated 2023-02-01 23:00 UTC)