Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Python Google

Golang Approves Generics, While Python Accepts Pattern-Matching Proposals (thenewstack.io) 84

Posted by EditorDavid from the having-a-type dept.
From today's "This Week in Programming" column: Rejoice, long at last, all you Gophers, for the question of whether or not the Go programming language will adopt generics has finally, after many years of debate, been answered this week with the acceptance of a proposal made last month.

In this most recent proposal, Golang team member Ian Lance Taylor writes that generics have been "one of the most commonly requested language features" since the language was first released in 2009, but even then, it's adoption doesn't come without concerns. Taylor explains the idea of generics in the intro of his proposal:

"Generics can give us powerful building blocks that let us share code and build programs more easily. Generic programming means writing functions and data structures where some types are left to be specified later. For example, you can write a function that operates on a slice of some arbitrary data type, where the actual data type is only specified when the function is called. Or, you can define a data structure that stores values of any type, where the actual type to be stored is specified when you create an instance of the data structure."

 It is precisely this value proposition — being able to write reusable code — that excites some developers and has been behind the push all along...

Generics wasn't the only controversial programming language addition this week, with the Python Steering Council making the decision to accept a number of Python Enhancement Proposals (PEPs) collectively known as the Pattern Matching PEPs. "We acknowledge that Pattern Matching is an extensive change to Python and that reaching consensus across the entire community is close to impossible," the council writes, saying that, nonetheless, they "are confident that Pattern Matching as specified in PEP 634, et al, will be a great addition to the Python language."

One dissenter to the addition found their way to the pages of iProgrammer, with the snarky headline "Python Adopts Pattern Matching — Kitchen Sink Next."
In other news, Google increased its support for the Python Software Foundation with a donation of more than $350,000 to support three specific projects, and also says it will continue its donation of Google Cloud infrastructure to the foundation.
This discussion has been archived. No new comments can be posted.

Golang Approves Generics, While Python Accepts Pattern-Matching Proposals More

Golang Approves Generics, While Python Accepts Pattern-Matching Proposals

Comments Filter:

  • lipstick on two pigs (Score:3, Informative)

    by cjonslashdot ( 904508 ) on Saturday February 13, 2021 @03:25PM (#61060226)

    Python: https://www.zdnet.com/article/... [zdnet.com]

    Go: http://valuedrivenit.blogspot.... [blogspot.com], https://www.golangprograms.com... [golangprograms.com]

    • It always amuses me when people display their cluelessness so publicly as these did.

      • Clueless? I've written compilers, and was on the team that created the VHDL language. I co-founded and was CTO of a 200-person company, and have written five books. I have advanced degrees from an Ivy League school in nuclear physics and operations research. Clueless?

        Guido van Rossum: "I've learned a painful lesson, that for small programs dynamic typing is great. For large programs, you have to have a more disciplined approach. And it helps if the language actually gives you that discipline, rather than te

        • What, you're one of those people linked? And do you also have over 300 confirmed kills and are trained in gorilla warfare?

          Also, I see your Rossum and raise you a Kay: "I’m not against types, but I don’t know of any type systems that aren’t a complete pain, so I still like dynamic typing." Mind you, Kay has a Turing Award and Rossum does not, so by your logic above Kay beats Rossum.

          • To each their own.

            Advantages of a type system:

            1. Refactoring tends to produce very few bugs.
            2. Reading code is easier, because it is easy to discover what type a variable is, and therefore what methods are available to it - saving one hours when trying to decipher someone else's methods, which return objects (one can tell at a glance what type the object is).

            Advantages of dynamic typing

            1. One saves a few seconds when writing a declaration.
            2. One can change one's mind about what kinds of things to store in a list, and
            • Coincidentally this brings me back to my original comment about some people being clueless. Sure, both typing options have their advantages and disadvantages depending on situation. But for example some people not getting how some other people could opt for dynamic typing apparently didn't think through the specific needs of evolving interactive systems...most often because they've never used them. They're then necessarily to grasp the design decisions, having never been confronted with the circumstances ne

              • Yes, this is insightful. There are pros and cons.

                Machine learning people lean toward Python because real ML people are not software developers: they are mathematicians. They want to run their neural network models - they don't care about programming. A neural network program is a simulation of a neural network. A true neural network runs on neuromorphic hardware and is not programmed.

                So ML people choose Python because it is very simple to learn and use, and they don't care about maintainability or software

    • --http://valuedrivenit.blogspot.com/2015/12/to-go-language-is-mess.html

      Wow....2015. So modules aren't included.

      Listen, go has it's problems (shadow variables anyone?) But that article is pretty bad.

      • Why is it bad? Out of date, yes. But I think that the points that I raised are all valid except for the modularity issue. Please be specific instead of making a general comment that is unaddressable. Thanks!

    • Go seems pretty elegant, in contrast to what that blog claims, but 5 months ago when I was wanting to learn a systems language for the first time, I skipped Go specifically because there were no generics, which is something I was already used to using in c# and Java and really didn't want to do without. Instead I learned Rust, which I was initially afraid of because of the lack of libraries and the difficulty in understanding the borrow checker, but I've actually gotten quite used to it and so far I'm not f

      • Yes, Rust tries to solve a problem that I wrote about in a book in 1997 (ownership of composite object trees), and that no other language (that I know of) solves, except for a language that I have been working on here and there (https://gitlab.com/cliffbdf/flow-poc). Functional languages try to solve the problem but in a bizarre and unnatural way, IMO.

  • Who proofreads anymore, and why is this so consistently ignored?

    • Do you think a site that regular posts the same story twice, a couple of days apart, is going to worry about shit spelling ?

      • Any automated grammar checker will catch this error.

        You don't need to think, or even know English. You just need to click the words with little red squiggly lines under them.

        • Any automated grammar checker will catch this error.

          "It's adoption, as well as improved health care, that reduces the rate of abortion."

          A counter-example showing that the phrase "it's adoption" is not ungrammatical. An automated grammar checker will not catch this error, because whether the phrase is an error depends on content.

        • The line between a spelling mistake and a grammar error is blurry.

          You just need to click the words with little red squiggly lines under them.
          The word in question was "it*s" ... it never will have a red line under it.

    • In the olden days, most people were only exposed to published works such as books, newspapers and magazines. These published works employed a position called an 'editor' that corrected such grammar mistakes.

      Only in recent times is the written language publicly disseminated for free by everyone and their monkey. Since no profits need to be made they do not employ an 'editor'. Also most of the public was not paying attention in school and do not know the difference. As bad grammar becomes more common it wi
    • This is a stupid grammar rule. When a rule only applies to one fucking word, it's more of an exception than a rule.
      • Are you serious, or seriously retarded? "It's" is a contraction of it is. "Don't", "haven't", "wouldn't", "here's", etc etc many more contractions.

        On the flip side, "its", "theirs", "yours", "ours", "hers".
        Neither applies to just one word.
        • First of all, get bent. Secondly, we're talking about "its" the possessive pronoun. Someone decided a long time ago that possessive nouns get the apostrophe and possessive pronouns (which there are only a dozen or so of) do not. "It's" a stupid rule.
          • And I gave you example of "ours" "theirs" etc, which are ALSO possessives without the apostrophes. Learn to read, and then fuck off.
            • Well you're certainly entitled to your opinion. Good day, sir.
              • "yours" "ours" "theirs" "hers" are not opinions, dickhead.

                They are parts of the English language taught from primary school. The non-apostrophe possessive is more than "its" and that's not an opinion, you dumb cunt.

              • Re: (Score:2)

                by DeVilla ( 4563 )

                Honest question. Which possessive pronoun (not noun) gets an apostrophe s?

                Mine, yours, ours, theirs, his, hers, its? ... vs Bob's.

                I'll admit it always felt like a stupid rule with its, but now that I think about it, there is a pattern.

          • Has nothing to do with it.

            "It's" is just short hand for "it is"

            If one is scared about errors, he always can use the long form, nothing wrong with that.

  • Gopher... (Score:3, Informative)

    by Dottie Matrix ( 7721008 ) on Saturday February 13, 2021 @03:42PM (#61060266) Homepage
    Raise your hand if you don't associate that word with the Go programming language and/or burrowing rodents.
  • Python included the kitchen sink long ago, though each silo has its own sink and they do not use the same water. At this point it is less a language and more a branding

    • Python included the kitchen sink long ago

      That is not a bad thing.

      Some languages, like C and Lisp, are inherently simple and elegant. Additional features are implemented with libraries, not language extensions.

      But others, such as Perl and C++, are inherently complex. They are will never win any beauty contests but are great if you just want to get stuff done. Since they are already ugly, there is little harm to glomming on more features.

      Python is more like an ugly workhorse. So I don't see a big problem with the new pattern matching functionali

      • Re: (Score:3)

        by jythie ( 914043 )
        I don't really have an issue with the specific change, but I think in general python has gotten too big with too much variation. I've been using it professionally for 12 years now, and I will sometimes work with other developers from other silos and can not make heads or tails of their code.. not because the formatting or style or even libraries are different, but actual different syntax. It has become a 'everything to everyone' language, but it is getting harder and harder to communicate with others abou
        • God forbid you'll have to learn new things after 12 years in a technical job...

        • Re: (Score:2)

          by steveha ( 103154 )

          I think in general python has gotten too big with too much variation.

          In general I think Python isn't too big; there's a common saying "Python fits my brain" because it's easy to hold the concepts of Python in your mind all at once.

          This new "pattern matching" syntax is a whole Pandora's box of new ideas. IMHO the jury is still out on whether it was a good idea. Guido van Rossum (GvR), the founder of Python, thinks it's a good idea and maybe he's right. I know at least one Python core developer who thinks

      • Additional features are implemented with libraries, not language extensions.
        Libraries can not "implement" additional language features.

        If you were a programmer you knew that.

        Or how exactly would you implement templates with a a library? Ah? Yeah, guessed so ...

        • Well, in Clojure (as simply an example with which I'm somewhat familiar with) one can find loads of libraries that implement some or other DSL (Domain-Specific Language). So for instance, can one write an HTML page in something that superficially and structure-wise looks very much like HTML, while at the same time being valid Clojure. (There are even multipe HTML libraries, which give fundamentally differing DSLs.)

          This is enabled by the homoiconicity of the language, which basically says there's no differe

          • Yes, homoiconic languages have an advantage there.
            But why would they not have use for generics (or better real templates?)

            • But why would they not have use for generics (or better real templates?)

              The fact that it's dynamically typed (the specific example mentioned) makes the use case for generics/templates quite weak. That's what I said, if you care to reread.

              The homoiconicity comes into play because it allows you to add some features to the language without waiting for the language to change. So someone has gone and added static typing (the author advocates using it when it makes sense, and not when it doesn't). And I'm under

        • Re: (Score:2)

          by Jeremi ( 14640 )

          Additional features are implemented with libraries, not language extensions.

          Libraries can not "implement" additional language features.

          I notice you inserted a word -- the person you quoted said "additional features", and you said "additional language features", which is not the same thing.

          If I write a library that parses JPG files, that's a new feature that other programs can use, although it is not a new language feature. See the difference?

          • If I write a library that parses JPG files, that's a new feature that other programs can use, although it is not a new language feature. See the difference?

            He meant language features. Which is obvious from the context.

            And a library is not a feature. As you simply can link any library from any language.

  • hold the line!

    and you if you live to tell your children's children, you were there on the day the abstract types attacked, and stood side by side and said you would not fall before the hordes and hordes of runtime type errors

    • Re: (Score:2)

      by Jezral ( 449476 )

      ...runtime type errors

      What? Generics can be fully instantiated at compile-time. There's no reason to defer this to runtime. I have no clue if Go will do it that compile-time safe way, but I know C++ does and it works great.

    • You seem to be confused about what exactly generics are. They are not abstract types, and they are checked/closed at compile time, not runtime.

  • Generics, makes me laugh. The computing world doesn’t just re-invent the wheel, it does so every 15 years or so.

    • q - but how does it touch the ground?

      a - it has a generic repetitive ground contact generator

      q - yeah but.. so like wheels?

      a - those are implementation details that can be left to the operations people

      q - so u bought a car with no wheels

      a - think about how efficiently we can create vehicles if we don't have to care about how they touch the ground

       

      • Yeah, funny ... how you miss the point.

        The idea is to separate an algoritm into the part that is the same for all types, and the part that is specific to a type for each type. This saves you from copy-pasting or re-implementing the same code over and over, and them going out of sync later, with one being fixed and all others still being buggy.

        Nobody says "implementation detail". You deliberately made that up as a straw man.

        Every compiler complains, if you want to use a generic algorithm that needs to have a

    • Re: (Score:2)

      by ceoyoyo ( 59147 )

      Well of course. All the strongly typed languages really would love to be weakly typed, but need plausible deniability.

  • Was adopting generics somehow controversial in the go community, or is there something about the language that makes doing them in a way that's consistent with the rest of the language tricky?

    • Comment removed based on user account deletion

      • Speed?

        Seriously?

        Get a clue ...

      • In any sane implementation, generics are entirely compiler based, so the runtime doesn't even know you've used them. (E.g. sorting an array of pointers does not need to know the content behind those pointers. Only that there is an implementation of the compare function for that type. Which the compiler will ask you to write. And which you can optimize as much as you want.).

    • Golang is built around being simple. Adding generics that were inline with the ethos of golang was a difficult task. Generics do add a benefit of reducing some code complexity at the cost of increasing obfuscation (in a way). Golang will never add operator overrides, on principle but still wants to be able to apply quick sort to any type that has a numeric value. Generics allow for simplifying certain algorithms in go and could provide a way for complex multithreaded / channel based libraries to apply acros

  • aka Lisp's sexy [xent.com] daughter,

    aer doomed to re-invent it. Badly. :)

Slashdot Top Deals

news: gotcha

Close