[HN Gopher] Make the Raku programming language familiar to C++ p...
___________________________________________________________________
Make the Raku programming language familiar to C++ programmers
Author : lizmat
Score : 57 points
Date : 2022-06-19 10:02 UTC (1 days ago)
(HTM) web link (software.gellyfish.co.uk)
(TXT) w3m dump (software.gellyfish.co.uk)
| bcatanzaro wrote:
| Just in time for C++23's long awaited std::print
|
| https://github.com/cplusplus/papers/issues/884
| samatman wrote:
| I like the niche Raku has carved out for itself, as a sort of
| experimental platform for writing software expressively.
|
| I don't use it, I probably won't, this kind of expressivity is
| something which feels good for developers but doesn't help them
| cooperate. The tradeoffs are probably not worth it.
|
| I'm glad it exists, though. It's a language where the users
| mostly find neat ways to say things, Perl is a great basis for
| that sort of language, and I wish them well.
| weare138 wrote:
| I've used Raku, it's actually pretty good. It's the first
| language I've used in a while that I genuinely enjoyed and had
| fun working with. Alot of the articles that get posted to HN
| about Raku are often like this one, showing how to push the
| envelope in Raku, but I wouldn't so so far as to call it an
| experimental language. Just like in the Perl tradition, you can
| do some straight voodoo in Raku but it's not required either.
| It's fairly straight forward on the surface and has all the
| familiar accoutrements of a modern language. You can be
| productive without having to delve into any of the esoteric and
| experimental stuff but can still get 'underneath the hood' if
| you need to.
| samatman wrote:
| The difference between experimental _platform_ and
| experimental _language_ is admittedly subtle, but I did mean
| platform.
|
| For anyone who just wants a cleaner Perl, it's there, it
| works. Descriptively, Raku as a 'scene' draws in a lot of
| people who come from the poetic school of Perl, which is
| great, it's clearly well designed for that crowd.
|
| I don't know that I'd call Raku battle-hardened yet, but it's
| not an experimental language in the sense of having novel
| semantics, or frequent breaking changes, nor would you expect
| to hit a bunch of implementation bugs.
|
| I'm not expecting many developers to decide to work in the
| large with a strict subset of Raku, because you can do that
| with Perl and get all of CPAN, or just use Python and black
| and have epsilon of zero problems of that nature.
| xisukar wrote:
| >I don't know that I'd call Raku battle-hardened yet
|
| You're right here, the Rakudo[1] compiler had its first
| stable release back in 2015 and comparatively speaking,
| there's a lot of space for growth.
|
| [1]: https://rakudo.org/
| pie_flavor wrote:
| I love Raku. Perl faced the same sort of pressure as PHP did to
| modernize and get rid of insanity, but where PHP modernized by
| sweeping all the insanity under the rug, Raku leaned _into_ the
| insanity and invented brand new modern forms of it. Global
| variables getting you down? Just use dynamically scoped
| variables, where assignment follows the call stack. Automatic
| conversion between strings and ints annoying? Stick it in the
| type system and let user-defined types implement the behavior
| too. Hate nulls? Use the class object itself as a typed null.
|
| So much of the language is so fundamentally _different_ from how
| languages are made in Current Year that I couldn 't begin to
| evaluate how useful or confusing these features are in the wild
| (especially operators like `ff`); I simply have zero context
| whatsoever for it.
| formerly_proven wrote:
| The despair of iostream coming to a language near you.
| captainbland wrote:
| Nothing wrong with the stl, their error messages are <std::iost
| ream::comment::__p<e<r<f<e<c<t<std::iostream::nesting::l<__y c>
| o> m>__p>r>e>__h>__n>s>I>b>l>e at line 13256 of
| inaccessibleandsomewhatobfuscatedheaderstream.hpp
| formerly_proven wrote:
| The STL and iostream are totally different libraries.
|
| STL is pretty much the foundational work of practical generic
| programming, while iostream is a trashfire of a feverdream
| someone had about "hey it'd be really cool if I overload
| operators to do I/O, wouldn't it? That would look so
| futuristic in code!1". The original STL implementation has
| even been formally verified.
|
| But you're right, modern stdlib implementations for C++ tend
| to be essentially obfuscated beyond any notion of
| readability.
| vmcs wrote:
| nowadays everyone does programming language
| dale_glass wrote:
| Raku is the new name for Perl 6, which began way back in the
| year 2000.
| xisukar wrote:
| >nowadays everyone does programming language
|
| By design/specification, Raku[0] is over 20 years old. The
| Rakudo[1] compiler is a lot younger, with its first stable
| release back in 2015.
|
| [0]: https://raku.org/
|
| [1]: https://rakudo.org/
| cestith wrote:
| If by "nowadays" you mean two decades ago up through now and by
| "everyone" you mean Larry Wall and the Perl community then I
| guess so.
| humanrebar wrote:
| I know this is a just for fun post, but C++ engineers haven't
| been especially happy with iostreams. {fmt} and std::format are
| more modern alternatives.
|
| And use of std::endl is widely considered an antipattern. Use of
| '\n' is always better for printing new lines.
| shadowfox wrote:
| > Use of '\n' is always better for printing new lines.
|
| Does this do the right thing on Windows?
| duped wrote:
| Unless you explicitly set O_BINARY on stdout/stderr then LF
| is converted to CRLF, aka "text mode" vs "binary mode" for
| files.
| afranchuk wrote:
| Yes! For the same reason it does the right thing in C APIs.
| Which many people don't realize (understandably) until they
| read the fine print in docs.
|
| If you read the specification of std::endl, it simply sends a
| "\n" and flushes.
| jcelerier wrote:
| > And use of std::endl is widely considered an antipattern. Use
| of '\n' is always better for printing new lines.
|
| people say that and then I loose half an hour trying to
| understand where my code is going wrong because my terminal did
| not flush when trying to debug log
| humanrebar wrote:
| When I want to flush, I use std::flush. Nothing about "endl"
| screams "this flushes", which is why nobody uses it. Also,
| flushing on every newline is a needless pessimization. Not
| that performance is everything, but it doesn't buy you much
| here.
|
| endl just saves you from getting out of the habit of using
| endl, really.
| UncleOxidant wrote:
| > Also, flushing on every newline is a needless
| pessimization.
|
| Maybe, but when you're debugging it's essential. Those
| debugging cout's aren't going to be there in production.
| Kranar wrote:
| >Nothing about "endl" screams "this flushes", which is why
| nobody uses it.
|
| Are you seriously suggesting no one uses std::endl? A
| simple search on Github actually reveals the opposite...
| almost everyone uses std::endl and almost no one uses
| std::flush (94% use std::endl, and 6% use std::flush).
|
| I am also in the std::endl camp and find it absurd when
| people bike shed over it. It's the most intuitive/least
| surprising behavior (based on Stack overflow questions) and
| how almost all other mainstream languages behave (flush on
| new line), and as such it should be the default choice.
|
| The use of ... << '\n' << std::flush is best when you want
| to explicitly call out that behavior because of performance
| reasons or some other exceptional circumstance.
| gusfrehse wrote:
| Just use cerr for debugging. It is not buffered so it always
| outuputs, even in unexpected crashes.
| jcelerier wrote:
| I wish it would but this is just not what I observe here, I
| have to flush explicitly to get things to show on the
| console
| int_19h wrote:
| std::cerr being unbuffered is one of its defining
| features. If you're not seeing that, either you (or some
| dependency you use) disables it, or it's a bug in your
| C++ stdlib.
| leni536 wrote:
| cerr should flush on \n too by default, AFAIK.
| baq wrote:
| cerr shouldn't be buffered... that's what clog is for
| leni536 wrote:
| Ah, I thought it was line-buffered, but apparently I was
| wrong.
___________________________________________________________________
(page generated 2022-06-20 23:02 UTC)