daotoad

Yet another way JavaScript has become more like Perl5. It now features `tie`. https://perldoc.perl.org/functions/tie.html

The internet was billed as the "Information Super-Highway" not the "Information Super-Railroad". That's why they didn't see it.

Or Perl 5. `do_stuff() if $a->y();` is a common idiom.

Or Perl 6. `do-stuff() if $a.y;` is the Perl6 version. You can even declare your variables to be sigil-less so you end up with `do-stuff() if a.y;` if you want. See my Perl6 Advent Calendar article for a quick tour of the language, available docs, with practical examples focusing on using Perl6's novel features to write a self documenting command line script.

https://perl6advent.wordpress.com/2018/12/16/

I've written code in everything from assembly to ML, Java, and Prolog. Perl6 is the only language I've used that I would "mind-expanding". The more I use it, the I realize how radical its design is.

No it's not.

Sophomoric joke notwithstanding, you've hit on the distinction between a thought out critique and mere criticism.

Perl in 1998. https://metacpan.org/pod/DBD::CSV Okay, 2002--it took a while before anyone bothered to write a shell. https://metacpan.org/pod/release/TLOWERY/DBI-Shell-11.9/lib/...

And there are drivers for everything from PostgreSQL and Oracle to text files and the Azure WMI.

What is best in life? To crush your comedy, to see played out before you, and to hear the felicitations of your patrons.

I have used Perl extensively in all of my last 4 jobs. The biggest reason companies that use Perl (that I am familar with) are looking at other languages is because it is hard to find developers.

That Python is fundamentally more readable is a myth. Unless by "readable" you mean that any Python program is superficially more visually similar to other Python programs than are programs in other languages. Syntactic white space will do that.

In comparing Python, Ruby and Perl, each relies to a certain extent on symbols in the code to express meaning. Python uses symbols very sparingly, and those it does use are either very much like other languages or established patterns from mathematics, even going so far as to ban braces for indicating structure--nothing is exotic. Perl is the opposite extreme, with to sigils encode variable context (which is a concept foreign to other language) and complex regular expression and quoting schemes built into to language. Ruby sits very much in the middle between these languages.

The use of all non-word symbols to densely encode meaning helps reduce code size at the cost of apparent readability. That's why you think Ruby is "more eloquent". Perl can be even more expressive than Ruby, but it's compactness can intimidate people, leading to defensive "humor".

Real readability comes from good structure and explicit code, whatever the language. It is especially important for developers using dynamic languages to document the contents of their data-structures.

If Python tends to be readable, it comes from a culture that values readability and focuses heavily on choosing a single, consistent style. Not from any inherent technical factor.

This is a nice piece on code readability in real life terms: http://www.pgbovine.net/python-unreadable.htm (TLDR: code may be readable in over small sections, but what really matters is whether you can understand the whole program. If you get lazy, you will make a mess. Be explicit.)

You need to take that basic form of "debugging" and turn it into instrumentation. Collect structured data and build tools to process it. Once you have a nice collection of data you can build profilers and execution traces, things classical debugging tools provide.

I've done it and the tools can work quite well. The same consistent instrumentation of your code also makes it easy to build really great dashboard monitoring.

All this time building tools costs money and adds complexity to your stack, so, yes, distribution had better be worth it for your business needs before you take it on. Pretty much like any engineering trade-off.

Level 0 is missing here. They want to know if they can afford rent AND food this month. They might be able to squeak by if nothing goes wrong. But something always does. Whether the 12 year old car needs an expensive repair or someone gets sick and misses work or even a parking ticket can leave them struggling to get by.

Also missing is level 4: I don't have to work to be at level 3 levels of comfort.

There's a tiny fraction who own significant wealth that are in a special level 5 or higher. "I don't care what anything costs."

Who edited this?

Nobody.

"weather this name is an acronym or..." An image labeled "A screen show of the Lisa..." which has multiple items clearly labeled as coming from a Mac... "Furthermore, Jobs had leaved the Lisa team..." Odd unattributed quotes from ??? The article asserts that Macintosh product design was key to its success. Then shows an original Macintosh with a Mac Color Classic 2 (a machine that hardly had an impact) but completely ignores the original clear iMacs (the computer which was part of revitalization of Apple and whose design owed much to the original Mac).

Well, you just blew your cover. They're watching you now.

Alternatively, everyone could pretend to be a muslim-environmentalist-communist with strong interests in nuclear chemistry and virology. It isn't possible to watch everyone.

Crap, they're gonna be watching me, now, too.

Are you sure you aren't an agent provocateur?

It's not an active racism on the part of the engineers. It's way more subtle than that.

There could be a hidden assumption on the part of the engineering team that light-skin is "normal" and anything else is a special case. Nobody is saying "I hate black people" or anything of the kind.

Or, as happened with a voice recognition system a former employer used, it was tested on the engineering staff, who happened to be all male. As a result it didn't work well for most women who tried to use it. There was no intentional exclusion of women from the test data, and I'd argue, no intentional exclusion of women from the engineering teams. But it is reasonable to say that systemic sexism that excludes women from engineering careers helped this system fail.

These kinds of problems are difficult to solve, because they aren't active decisions on anyone's part. They evolve out of pervasive conditions, and unconscious biases. At root, the source is still racism, or sexism (or another form of discrimination).

---OFF TOPIC: WORD USAGE---

Do ad hock networks lead to fetlock-in?

A hock is a joint in the lower end of a quadruped's hind leg, between the knee and fetlock. It's in analogous position to the ankle in humans.

Of course 'hock' can also mean 'to sell, especially to a pawn broker'.

The word you want is 'hoc' which is Latin for 'this'. You may be familiar with the 'post hoc' fallacy: which is that if event A is followed by event B, event B must therefore be caused by event A. The full name of the fallacy is 'post hoc, ergo propter hoc', which means 'after this, therefore because this'.

The latin word 'ad' simply mean 'to' or 'for'. So 'ad astra' means 'to the stars', an 'ad hominem' argument is to literally direct your argument 'to the person' and their faults.

So finally we arrive at the combination 'ad hoc', which means 'to the purpose'. Ad hoc things are done in purely pragmatic manner, for a particular purpose. They are often short lived arrangements which end once their purpose has been meet or is made moot.

Oh, and you didn't make this mistake, but I'm going to blather about it anyway. 'etc.' is short for 'et cetera', it is not spelled 'ect.', nor 'excetera', nor is the usage 'and etc.' valid. 'et cetera' means literally 'and the rest'--meaning anything, not necessarily just the Professor and Maryanne.

Disappointing, but not really surprising.

Yes the actual laws of physics can't be broken. We don't know those. We know an approximation of them based on centuries of careful observation and analysis. That approximation is incredibly good, too. It lets us make microchips with 7nm features, synthesize high atomic weight elements, and build spacecraft that have traversed the solar system. Even so, there are things we know we don't know and there are bound to be things we don't know we don't know.

It would be nice if the EmDrive turned out to be a ground breaking demonstration of a hole in our model. We could probably squeeze a century of amazing science out of it. Not to mention the potential practical applications.

But groundbreaking new discoveries that shake the foundations of a developed scientific theory are incredibly rare. So, as awesome as it could be if it were right, the odds were always against it.

That's why brutalist architecture works best when it includes large windows and sky lights.

What makes the brutalist buildings in the Pacific Northwest beautiful is that many of them are now covered in vegetation, with mosses or vines muting their harshness.

That said, this so-called "brutalist web design" is bullshit. It's just avant-garde design of the 80s applied to web pages.

Yawn. We've had this in Perl for decades using the DBI Shell (dibsh). DBI is a common database interface. To connect to a data source, one uses an appropriate driver (by convention, in the DBD name space, such as DBD::Pg or DBD::MySQL) to get a db handle that can run SQL commands. There are a lot of drivers for things like CSV files, in memory database, etc.

Plus you can access all this programmatically and not just through the dbish command. Since this is a central part of Perl infrastructure, there are a ton of tools that extend the DBI, from a variety of ORMs like DBIx::Class, to data export and even DDL delta management.

Generalized Database Interface: https://metacpan.org/pod/DBI DBI Shell program: https://metacpan.org/pod/DBI::Shell CSV driver: https://metacpan.org/pod/DBD::CSV

Also, lumping in the lack of accountability for police and prison guards with, say, accountability for teachers is laughable. Police and correctional officers have specific, strong protections from legal consequences for their actions.

Perl 5's twofold approach to solving this mess is to use compile time checks to manage new features. The use VERSION syntax lets you specify a version of perl. The feature pragma lets you enable or disable new features on a case by case basis. In my experience, this works really well.

The feature pragma (see https://perldoc.perl.org/feature.html) lets you manage new features on an individual basis. You just write: feature NAME_OF_FEATURE;. For example, feature signatures; In this case adding subroutine/method signature support. This is a compile time check.

If you don't want to hassle with enabling features on a piecemeal basis, you can also specify a version of perl you wish to rely on with use VERSION (see https://perldoc.perl.org/functions/use.html). For example, if want all of the standard features of perl 5.26.1, you say use v5.26.1.

I've used grid with IE11. You need to add some extra prefixing noise to your css. The way you identify grid elements is different and it sucks to duplicate the layout information.

But it most definitely works.

Nice work, it looks pretty slick. You have a right to be proud of your work.

But....

IMO, the project name is a disaster.

If successful it will muddy the water on searches for RxJS (and other Rx) observables.

Please do like the Amber.js team did when they learned of a name comflict and rebrand as Ember.js. That would be awesome.

Yes. IME, once a service is dialed in, it should need little maintenance. That's how my team was able to handle responsibility for 5+ services on top of our slowly carved up monolith.

If your microservice code is significantly harder to manage than your monolith, you've factored it wrong. Which means you shouldn't find yourself constantly working on 6 or 7 different services at once. If so, try a different decomposition.

Saying one team per service is like saying "a team should only handle one or two classes".

IME we had multiple services for each team. But we were in the process of carving several mutually incompatible whales into common, shared services, YMMV. So we had one team maintaining each whale, and our senior engineers would collaborate to identify pieces that could be cut from each and replaced with a common service. If the innards of one whale matched our service better than the others, that whale's team got to write the service. Eventually all the teams would port their products to the new, resulting service.

This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations.

If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.

Swagger is the basis and a great implementation of OpenAPI which is a standard.

https://www.openapis.org

Perl is essentially a pigdin or creole language composed of C, shell, awk, sed and POSIX concepts with bits of Lisp thrown in.

If you know Unix, you will already know about 80% of perl. If you know Perl well, you already know a lot of Unix concepts.

Perl is a pain to learn if you don't have a solid Unix background. However, IME, if you acknowledge the sources Perl draws from, look at how they're integrated, and spend some time learning the underlying technical culture, it actually simplifies the learning process.

Interestingly enough, it's also easier to learn a natural language if you spend some time learning the underlying culture.

Unless we can come up with some sweet carbon sequestration tech, that's actually a liability.

This looks pretty interesting to me. But it leads to a lot of questions that are unanswered on the webpage.

The claims of 30% faster for a particular workload are reasonable, but what configuration is needed and what exact workload are we talking about? I'd love to see some benchmarking code.

What are the limitations imposed by running in memcached mode? Can you still do clustering?

What other changes are they planning? Site just says "many". Are we talking about memory allocation or persistence changes? Maybe additional interface compatibility modes? It's hard to bet on this when we don't have any idea what else it will bring to the table.

Where possible, I'd really like to see these improvements factored into distinct redis modules and made available as plugins to the core.

Something like this maybe? https://www.perl.com/pub/2005/06/23/sprog.html

Scrapy? Really?

Scrapie is a transmissible spongiform ecephalopathy, similar to mad cow disease, in sheep and goats.

https://en.wikipedia.org/wiki/Scrapie

Tech interviews are 40 minutes max? Where are you interviewing?

I have seen far more 6+ hour interview loops that 40 minute ones.

Maybe each session within the full loop accounts for 40 minutes.

That being said, people have their pet questions they use to sort the wheat from the chaff--if you can't fizzbuzz your way out of a wet paper bag, I am not hiring you. The best questions are more about process than the final answer. Solve an easyish problem, add some features, add some more features. What other ways could you have solved that problem? Why did you choose this way? When would you use a different approach? How does your solution scale?

The worst questions are gotcha questions with a right and wrong answer, `what does the C99 standard indicate is the correct size of a stack frame?`