An anonymous reader quotes a blog post by Curtis Poe , a freelance Perl/Agile/testing consultant and the author of the Wrox book Beginning Perl: By now, many of you have seen the Perl 6 Github issue "Perl" in the name "Perl 6" is confusing and irritating. The issue suggested renaming Perl 6. While some may think that the name of the issue is trolling, or offensive, the actual issue was created by Elizabeth (Liz) Mattijsen, one of the core Perl 6 developers, a long-time Perl 5 developer, and with her spouse, Wendy, has long been an enthusiastic support of Perl 5/6. There is no trolling here. There is a lot of deep thought, careful discussion, and a genuine desire to find a way to bypass some deeply divisive issues in the Perl community.

While the proposed name was "camelia", Damian Conway made a strong argument in favor of "raku" and it appears the community is leaning towards this name for various reasons... The far, far too terse backstory: the Perl 6 community seems to be split between those who view Perl 6 as a sister language to Perl 5 and those who view Perl 6 as a successor to Perl 5...

To say that this issue has been bitterly divisive would be an understatement.

Long-time Slashdot reader mejustme shared this report from Hackaday: If you have an opinion about C++, chances are you either love it for its extensiveness and versatility, or you hate it for its bloated complexity and would rather stick to alternative languages on both sides of the spectrum. Either way, here's your chance to form a new opinion about the language. The C++ standard committee has recently gathered to work on finalizing the language standard's newest revision, C++20, deciding on all the new features that will come to C++'s next major release.

After C++17, this will be the sixth revision of the C++ standard, and the language has come a long way from its "being a superset of C" times. Frankly, when it comes to loving or hating the language, I haven't fully made up my own mind about it yet. My biggest issue with it is that "programming in C++" can just mean so many different things nowadays, from a trivial "C with classes" style to writing code that will make Perl look like prose. C++ has become such a feature-rich and downright overwhelming language over all these years, and with all the additions coming with C++20, things won't get easier. Although, they also won't get harder. Well, at least not necessarily. I guess? Well, it's complex, but that's simply the nature of the language...

From better type checking and compiler errors messages to Python-like string handling and plans to replace the #include system, there's a lot at play here!
The article mentions coroutines, the spaceship operator for three-way comparisons, and "a bunch of additions to lambda expressions," as well as a new keyword constinit and removing limitations on the usage of constexpr.

And in addition, "ranges are the new iterators" and concepts "have graduated from being an experimental feature to a full-fledged part of the language standard, allowing the addition of semantic constraints to templates, and ultimately making generic programming a hint more specific."

An anonymous reader shares a report: Not all programming languages endure forever. In fact, even the most popular ones inevitably crumble away, as new generations of developers embrace other languages and frameworks they find easier to work with. In order to determine which programming languages are likely doomed in the medium- to long-term, we looked at the popularity rankings by TIOBE and RedMonk, as well as Dice's own database of job postings. If your career is based on any of the following languages, we suggest diversifying your skill-set at some point: Ruby, Haskell, Objective-C, R, and Perl.

An anonymous reader quotes The Verge's AI and Robotics reporter: By scanning huge datasets of text, machine learning software can produce convincing samples of everything from short stories to song lyrics. Now, those same techniques are being applied to the world of coding with a new program called Deep TabNine, a "coding autocompleter." Programmers can install it as an add-on in their editor of choice, and when they start writing, it'll suggest how to continue each line, offering small chunks at a time. Think of it as Gmail's Smart Compose feature but for code.

Jacob Jackson, the computer science undergrad at the University of Waterloo who created Deep TabNine, says this sort of software isn't new, but machine learning has hugely improved what it can offer... Earlier this month, he released an updated version that uses a deep learning text-generation algorithm called GPT-2, which was designed by the research lab OpenAI, to improve its abilities. The update has seriously impressed coders, who have called it "amazing," "insane," and "absolutely mind-blowing" on Twitter...

Deep TabNine is trained on 2 million files from coding repository GitHub. It finds patterns in this data and uses them to suggest what's likely to appear next in any given line of code, whether that's a variable name or a function... Most importantly, thanks to the analytical abilities of deep learning, the suggestions Deep TabNine makes are of a high overall quality. And because the software doesn't look at users' own code to make suggestions, it can start helping with projects right from the word go, rather than waiting to get some cues from the code the user writes.
It's not free software. Currently a personal license costs $49 (with a business-use license costing $99), the Verge reports -- but the tool supports the following 22 languages...

Python, JavaScript, Java, C++, C, PHP, Go, C#, Ruby, Objective-C, Rust, Swift, TypeScript, Haskell, OCaml, Scala, Kotlin, Perl, SQL, HTML, CSS, and Bash.

In honor of FreeDOS's 25th birthday, project founder and coordinator Jim Hall agreed to answer the 10 best questions submitted by Slashdot readers. You asked and he answered! Read on for Jim's interview.

"At the first annual charity event conducted by Puget Sound Programming Python on April 2, four legendary language creators came together to discuss the past and future of language design," reports PacktPub.

- Guido van Rossum, the creator of Python
- James Gosling, the founder, and lead designer behind the Java programming language
- Anders Hejlsberg, the original author of Turbo Pascal who has also worked on the development of C# and TypeScript
- Larry Wall, the creator of Perl

You can watch the video here -- the speaker introductions start about 50 minutes into the video-- or read PacktPub's summary of the event: Guido van Rossum said designing a programming language is very similar to the way JK Rowling writes her books, the Harry Potter series... He says JK Rowling is a genius in the way that some details that she mentioned in her first Harry Potter book ended up playing an important plot point in part six and seven... When designing a language we start with committing to certain details like the keywords we want to use, the style of coding we want to follow, etc. But, whatever we decide on we are stuck with them and in the future, we need to find new ways to use those details, just like Rowling...

When James Gosling was asked how Java came into existence and what were the design principles he abided by, he simply said, "it didn't come out of like a personal passion project or something. It was actually from trying to build a prototype.... It started out as kind of doing better C and then it got out of control that the rest of the project really ended up just providing the context." In the end, the only thing out of that project survived was Java...

Larry Wall wanted to create a language that was more like a natural language. Explaining through an example, he said, "Instead of putting people in a university campus and deciding where they go we're just gonna see where people want to walk and then put shortcuts in all those places." A basic principle behind creating Perl was to provide APIs to everything. It was aimed to be both a good text processing language linguistically but also a glue language....

Similar to the views of Guido van Rossum, Anders Hejlsberg adds that any decision that you make when designing a language you have to live with it. When designing a language you need to be very careful about reasoning over what "not" to introduce in the language.
There was also some discussion of types -- Gosling believes they help improve performance, while Hejlsberg said types are also useful when building coding tools. "It turns out that you can actually be more productive by adding types if you do it in a non-intrusive manner and if you work hard on doing good type inference and so forth." In fact, Hejlsberg told the audience that the TypeScript project was inspired by massive "write-only" JavaScript code bases, while a semantic understanding (including a type system) makes refactoring easier.

Guido van Rossum acknowledged that TypeScript "is actually incredibly useful and so we're adding a very similar idea to Python. We are adding it in a slightly different way because we have a different context.... 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 telling you, 'Well, you can do whatever you want.'"

In the video Larry Wall says the Perl 6 team had also noticed the limitations of loose typing, and added a robust type system to Perl 6 to "help with programming in the large."

This was the first annual benefit for CSforALL, a group promoting high-quality computer science classes at every grade level.

For software engineers, lack of friction is an aesthetic joy, an emotional high, the ideal existential state. It's what drives them, and what shapes our world. An excerpt from an upcoming book on coding, via Wired: The thrust of Silicon Valley is always to take human activity and shift it into metabolic overdrive. And maybe you've wondered, why the heck is that? Why do techies insist that things should be sped up, torqued, optimized? There's one obvious reason, of course: They do it because of the dictates of the market. Capitalism handsomely rewards anyone who can improve a process and squeeze some margin out. But with software, there's something else going on too. For coders, efficiency is more than just a tool for business. It's an existential state, an emotional driver.

Coders might have different backgrounds and political opinions, but nearly every one I've ever met found deep, almost soulful pleasure in taking something inefficient -- even just a little bit slow -- and tightening it up a notch. Removing the friction from a system is an aesthetic joy; coders' eyes blaze when they talk about making something run faster or how they eliminated some bothersome human effort from a process. This passion for efficiency isn't unique to software developers. Engineers and inventors have long been motivated by it. During the early years of industrialization, engineers elevated the automation of everyday tasks to a moral good. The engineer was humanity's "redeemer from despairing drudgery and burdensome labor," as Charles Hermany, an engineer himself, wrote in 1904.

[...] Many of today's programmers have their efficiency "aha" moment in their teenage years, when they discover that life is full of blindingly dull repetitive tasks and that computers are really good at doing them. (Math homework, with its dull litany of exercises, was one thing that inspired a number of coders I've talked to.) Larry Wall, who created the Perl programming language, and several coauthors wrote that one of the key virtues of a programmer is "laziness" -- of the variety where your unwillingness to perform rote actions inspires you to do the work to automate them.

Linus Torvalds: I can pretty much guarantee that as long as everybody does cross-development, the platform won't be all that stable. Or successful. Some people think that "the cloud" means that the instruction set doesn't matter. Develop at home, deploy in the cloud. That's bullshit. If you develop on x86, then you're going to want to deploy on x86, because you'll be able to run what you test "at home" (and by "at home" I don't mean literally in your home, but in your work environment). Which means that you'll happily pay a bit more for x86 cloud hosting, simply because it matches what you can test on your own local setup, and the errors you get will translate better. This is true even if what you mostly do is something ostensibly cross-platform like just run perl scripts or whatever. Simply because you'll want to have as similar an environment as possible.

Which in turn means that cloud providers will end up making more money from their x86 side, which means that they'll prioritize it, and any ARM offerings will be secondary and probably relegated to the mindless dregs (maybe front-end, maybe just static html, that kind of stuff). Guys, do you really not understand why x86 took over the server market? It wasn't just all price. It was literally this "develop at home" issue. Thousands of small companies ended up having random small internal workloads where it was easy to just get a random whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it became a "real server". And then once that thing expanded, suddenly it made a whole lot of sense to let somebody else manage the hardware and hosting, and the cloud took over. Do you really not understand? This isn't rocket science. This isn't some made up story. This is literally what happened, and what killed all the RISC vendors, and made x86 be the undisputed king of the hill of servers, to the point where everybody else is just a rounding error. Something that sounded entirely fictional a couple of decades ago. Without a development platform, ARM in the server space is never going to make it. Trying to sell a 64-bit "hyperscaling" model is idiotic, when you don't have customers and you don't have workloads because you never sold the small cheap box that got the whole market started in the first place.

An anonymous reader writes: Saturday the Perl Advent Calendar entered its 19th year by describing how the Wise Old Elf used a Calendar::List module from CPAN to update his Elven Perl Monger website with all the dates for 2019. ("It is a well known fact that all of Santa's Elves are enthusiastic Perl Developers in their free time, contributing regularly to many of the amazing Perl projects we've come to know and love...")

But meanwhile, the Perl 6 Advent Calendar was describing how Santa gets data into the North Pole's CRM by defining a grammar unit which can be parsed using a built-in method (to trim out children's signatures) -- only to be chastised by his IT elf for failing to document his solution using Perl 6's built in markup language.

And 24Ways.org is also presenting its 14th annual "advent calendar for web geeks," a nicely-formatted offering that promises "a daily dose of web design and development goodness to bring you all a little Christmas cheer."

Meanwhile, the Go language site Gopher Academy launched their 6th annual advent calendar, describing how to split data with content-defined chunking.

Jose Valim, creator of the Elixir programming language, has also announced the fourth annual "Advent of Code," an event created by Eric Wastl that features an ongoing story that presents "a series of small programming puzzles for a variety of skill sets and skill levels in any programming language you like." (The folks behind the Nim programming language are even organizing their own leaderboard at Nim-lang.org.)

And even QEMU, a free and open-source emulator performing hardware virtualization, is getting into the act with a QEMU advent calendar offering "an amazing QEMU disk image" each day through December 24th.
Feel free to leave a comment with your own reactions -- or with the URL for your own favorite online geek advent calendars...

An anonymous reader quotes InsideHPC: Today Julia Computing announced the Julia 1.0 programming language release, "the most important Julia milestone since Julia was introduced in February 2012." As the first complete, reliable, stable and forward-compatible Julia release, version 1.0 is the fastest, simplest and most productive open-source programming language for scientific, numeric and mathematical computing. "With today's Julia 1.0 release, Julia now provides the language stability that commercial customers require together with the unique combination of lightning speed and high productivity that gives Julia its competitive advantage compared with Python, R, C++ and Java."
The Register reports: Created by Jeff Bezanson, Stefan Karpinski, Viral Shah, and Alan Edelman, the language was designed to excel at data science, machine learning, and scientific computing.... Six years ago, Julia's creators framed their goals thus:

"We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled...."

In a julialang.org post announcing the milestone, the minders of the language claim to have achieved some of their goals.

Slashdot reader silverdirk writes: Compiled languages have long provided access to the OpenGL API, and even most scripting languages have had OpenGL bindings for a decade or more. But, one significant language missing from the list is our old friend/nemesis Bash. But worry no longer! Now you can create your dazzling 3D visuals right from the comfort of your command line!
"You'll need a system with both Bash and OpenGL support to experience it firsthand," explains software engineer Michael Conrad, who created the first version 13 years ago as "the sixth in a series of 'Abuse of Technology' projects," after "having my technical sensibilities offended that someone had written a real-time video game in Perl.

"Back then, my primary language was C++, and I was studying OpenGL for video game purposes. I declared to my friends that the only thing worse would be if it had been 3D and written in Bash. Having said the idea out loud, it kept prodding me, and I eventually decided to give it a try to one-up the 'awfulness'..."

InfoWorld reports that "the once-declining C language" has "completed a comeback" -- citing its rise to second place in the Tiobe Index of language popularity, the biggest rise of any language in 2017. An anonymous reader quotes their report: Although the language only grew 1.69 percentage points in its rating year over year in the January index, that was enough beat out runners-up Python (1.21 percent gain) and Erlang (0.98 percent gain). Just five months ago, C was at its lowest-ever rating, at 6.477 percent; this month, its rating is 11.07 percent, once again putting it in second place behind Java (14.215 percent) -- although Java dropped 3.05 percent compared to January 2017. C's revival is possibly being fueled by its popularity in manufacturing and industry, including the automotive market, Tiobe believes...

But promising languages such as Julia, Hack, Rust, and Kotlin were not able to reach the top 20 or even the top 30, Tiobe pointed out. "Becoming part of the top 10 or even the top 20 requires a large ecosystem of communities and evangelists including conferences," said Paul Jansen, Tiobe managing director and compiler of the index. "This is not something that can be developed in one year's time."
For 2017 Tiobe also reports that after Java and C, the most popular programming languages were C++, Python, C#, JavaScript, Visual Basic .Net, R, PHP, and Perl.

The rival Pypl Popularity of Programming Language index calculates that the most popular languages are Java, Python, PHP, JavaScript, C#, C++, C, R, Objective-C, and Swift.

An anonymous reader writes: A long-time Unix sys-admin is suggesting 18 different New Year's resolutions for Linux systems adminstrators. And #1 is to automate more of your boring stuff. "There are several good reasons to turn tedious tasks into scripts. The first is to make them less annoying. The second is to make them less error-prone. And the last is to make them easier to turn over to new team members who haven't been around long enough to be bored. Add a small dose of meaningful comments to your scripts and you have a better chance of passing on some of your wisdom about how things should be done."

Along with that, they suggest learning a new scripting language. "It's easy to keep using the same tools you've been using for decades (I should know), but you might have more fun and more relevance in the long run if you teach yourself a new scripting language. If you've got bash and Perl down pat, consider adding Python or Ruby or some other new language to your mix of skills."

Other suggestions include trying a new distro -- many of which can now be run in "live mode" on a USB drive -- and investigating the security procedures of cloud services (described in the article as "trusting an outside organization with our data").

"And don't forget... There are now only 20 years until 2038 -- The Unix/Linux clockpocalypse."

Several popular interpreted programming languages are affected by severe vulnerabilities that expose apps built on these languages to attacks, according to research presented at the Black Hat Europe 2017 security conference. An anonymous reader writes: The author of this research is IOActive Senior Security Consultant Fernando Arnaboldi, who says he used an automated software testing technique named fuzzing to identify vulnerabilities in the interpreters of five of today's most popular programming languages: JavaScript, Perl, PHP, Python, and Ruby.

Fuzzing involves providing invalid, unexpected, or random data as input to a software application. The researcher created his own fuzzing framework named XDiFF that broke down programming languages per each of its core functions and fuzzed each one for abnormalities. His work exposed severe flaws in all five languages, such as a hidden flaw in PHP constant names that can be abused to perform remote code execution, and undocumented Python methods that can be used for OS code execution. Arnaboldi argues that attackers can exploit these flaws even in the most secure applications built on top of these programming languages.

An anonymous reader writes: Friday saw this year's first new posts on the Perl Advent Calendar, a geeky tradition first started back in 2000. It describes Santa including Unicode's "Father Christmas" emoji by enabling UTF-8 encoding and then using the appropriate hexadecimal code.

But in another corner of the North Pole, you can also unwrap the Perl 6 Advent Calendar, which this year celebrates the two-year anniversary of the official launch of Perl 6. Its first post follows a Grinch who used the but and does operators in Perl 6, while wrapping methods and subroutines to add extra sneaky features, "and even mutated the language itself to do our bidding."

Perl/Python guru Joel Berger has also started an advent calendar for the Mojolicious web application framework (written in Perl), and there's apparently also an advent calendar coming for the Perl Dancer web application framework.

Thomas Claburn, writing for The Register: Developers really dislike Perl, and projects associated with Microsoft, at least among those who volunteer their views through Stack Overflow. The community coding site offers programmers a way to document their technical affinities on their developer story profile pages. Included therein is an input box for tech they'd prefer to avoid. For developers who have chosen to provide testaments of loathing, Perl tops the list of disliked programming languages, followed by Delphi and VBA. The yardstick here consists of the ratio of "likes" and "dislikes" listed in developer story profiles; to merit chart position, the topic or tag in question had to show up in at least 2,000 stories. Further down the down the list of unloved programming language comes PHP, Objective-C, CoffeeScript, and Ruby. In a blog post seen by The Register ahead of its publication today, Stack Overflow data scientist David Robinson said usually there's a relationship between how fast a particular tag is growing and how often it's disliked. "Almost everything disliked by more than 3 per cent of Stories mentioning it is shrinking in Stack Overflow traffic (except for the quite polarizing VBA, which is steady or slightly growing)," said Robinson. "And the least-disliked tags -- R, Rust, TypeScript and Kotlin -- are all among the fast-growing tags (TypeScript and Kotlin growing so quickly they had to be truncated in the plot)."

"I was trained more as a linguist than a computer scientist," says Perl creator Larry Wall, "and some people would say it shows." An anonymous reader describes Wall's new video interview up on InfoQ: "With a natural language, you learn it as you go," Wall says. "You're not expected to know the whole language at once. It's okay to have dialects... Natural languages evolve over time, and they don't have arbitrary limits. They naturally cover multiple paradigms. There are external influences on style... It has fractal dimensionality to it. Easy things should be easy, hard things should be possible. And, you know, if you get really good at it, you can even speak CompSci."

Wall also touched on the long delay for the release of Perl 6. "In the year 2000, we said 'Maybe it's time to break backward compatibility, just once. Maybe we can afford to do that, get off the worse-is-worse cycle, crank the thing once for a worse-is-better cycle." The development team received a whopping 361 suggestions -- and was also influenced by Paul Graham's essay on the 100-year language. "We put a lot of these ideas together and thought really hard, and came up with a whole bunch of principles in the last 15 years." Among the pithy principles: "Give the user enough rope to shoot themselves in the foot, but hide the rope in the corner," and "Encapsulate cleverness, then reuse the heck out of it.."

But Wall emphasized the flexibility and multi-paradigm nature that they finally implemented in Perl 6. "The thing we really came up with was... There really is no one true language. Not even Perl 6, because Perl 6 itself is a braid of sublanguages -- slangs for short -- and they interact with each other, and you can modify each part of the braid..."
Wall even demoed a sigil-less style, and argued that Perl 6 was everything from "expressive" and "optimizable" to "gradually-typed" and "concurrency aware," while supporting multiple virtual machines. He also notes that Perl 6 borrows powerful features from other languages, including Haskell (lazy evaluation) Smalltalk (traits), Go (promises and channels), and C# (functional reactive programming).

And towards the end of the interview Wall remembers how the original release of Perl was considered by some as a violation of the Unix philosophy of doing one thing and doing it well. "I was already on my rebellious slide into changing the world at that point."

An anonymous reader writes: Saturday night saw the announcement of an experimental Perl 5 to Java compiler. "This is the first release," posted developer FlÃvio S. Glock -- after 100 weeks of development. "Note that you don't need to compile a Java file. Perlito5 now compiles the Perl code to JVM bytecode in memory and executes it." He describes the compiler as "a work-in-progress" that "provides an impressive coverage of Perl features, but it will not run most existing Perl programs due to platform differences."

An anonymous reader writes: Google "developer advocate" Felipe Hoffa has determined the top "weekend programming languages," those which see the biggest spike in commit activity on the weekends. "Clearly 2016 was a year dedicated to play with functional languages, up and coming paradigms, and scripting 3d worlds," he writes, revealing that the top weekend programming languages are:

Rust, Glsl, D, Haskell, Common Lisp, Kicad, Emacs Lisp, Lua, Scheme, Julia, Elm, Eagle, Racket, Dart, Nsis, Clojure, Kotlin, Elixir, F#, Ocaml

Earlier this week another data scientist calculated ended up with an entirely different list by counting the frequency of each language's tag in StackOverflow questions. But Hoffa's analysis was performed using Google's BigQuery web service, and he's also compiled a list of 2016's least popular weekend languages -- the ones people seem to prefer using at the office rather than in their own free time.

Nginx, Matlab, Processing, Vue, Fortran, Visual Basic, Objective-C++, Plsql, Plpgsql, Web Ontology Language, Smarty, Groovy, Batchfile, Objective-C, Powershell, Xslt, Cucumber, Hcl, Puppet, Gcc Machine Description

What's most interesting is the changes over time. In the last year Perl has become more popular than Java, PHP, and ASP as a weekend programming language. And Rust "used to be a weekday language," Hoffa writes, but it soon also grew more popular for Saturdays and Sunday. Meanwhile, "The more popular Go grows, the more it settles as a weekday language," while Puppet "is the champion of weekday coders." Ruby on the other hand, is "slowly leaving the week and embracing the weekend."
Hoffa is also a long-time Slashdot reader who analyzed one billion files on GitHub last summer to determine whether they'd been indented with spaces or tabs. But does this new list resonate with anybody? What languages are you using for your weekend coding projects?

Reader joshtops writes: I know this is a question that must have been asked -- and answered -- on Slashdot several times, but I am hoping to listen from the community again (fresh perspective, if you will). I'm in my 20s, and have a day job that doesn't require any programming skills. But I want to learn it nonetheless. I have done some research but people have varied opinions. Essentially my question is: What is perhaps the best way to learn programming for my use case? I am looking for best possible resources -- perhaps tutorials on the internet, the right books and the order in which I should read/watch them. Some people have advised me to start with C language, but I was wondering if I could kickstart things with other languages such as perhaps Apple's Swift as well?