HN user

dugword

127 karma
Posts1
Comments48
View on HN

The good news is most business problems are not that hard.

There are domains where you really have to be a crackerjack engineer, but most jobs just need you to know how to push and pull things out of datastores, make network requests, map data structures, and maybe render the results on a web page.

Technical job interviewers loves to grill candidates on reversing binary trees, or obscure programming language trivia -- but the job itself will be building a CRUD app.

So what should you do? If you enjoy programming, I'd say stick with it. Not everyone needs to be working on ground breaking cryptography or compiler optimizations. Sounds like you just need to find a tech stack and problem space where you can feel comfortable working on it.

History. Of the world, of your country, of your profession and other industries.

Things are the way they are because of how they used to be.

That context paints everything. The more you understand it, the better you will be able to work within it, and predict what will happen next.

Because negative news articles about cannabis are almost always flimsy studies trying to spread fear and push an agenda.

If cannabis was legal everywhere almost no one would care about these studies.

However, cannabis is illegal in most places and there is a battle for opinions where groups are trying to spread FUD about how "weed is killing babies".

It's fighting for people to have a rational stance and pushing for policies that don't imprison people over a substance on par with alcohol that brings out the defenders on any article like this.

You add 'hello' in the linter's config as a pre-defined global, until you get around to fixing that.

I would not want my linter to load multiple files, since that pattern of polluting the global namespace is really not maintainable.

The fix can be fairly simple if you wrap your entire b.js file in a function that takes an argument of 'hello' which you invoke from a.js.

If that doesn't work because you have too many global declarations you should probably just dump all the code into one giant file.

That might seem terrible and unmaintainable, but it is exactly what you already have.

Once the mess is all in one spot you can use a linter to start improving the quality, and begin breaking of the code into actual modules.

I have taken a similar approach where I start with having 0 lint issues, and add a git hook or CI step to only allow merges with 0 lint issues.

Except instead of modifying my config over time, I add a /* eslint ignore */ to the top of every existing file.

Every new file will be coded to the new standard, and as I open old files to tweak them I take the opportunity to clean them up.

Knowledge and learning can be it's own reward. But if you need the motivation to build something you know has already been done, and probably done better, think about it as building the skills necessary to create something of value later.

Also, as you build and learn you'll discover new things you could be learning and come up with solutions to problems that haven't been solved.

Based on how low it is on the rankings compared to other languages I'd say not many.

I have no data to back this up other than my anecdotal personal experience but I'd wager Perl hackers who use Homebrew never use it to install Perl.

Most of the classic Perl documentation walks you through installing from source, which is quite easy, and modern documentation/tutorials usually refer to perlbrew.

The Perl community often has established solutions within their own ecosystem, and this makes them seem like they have a smaller presence then the otherwise would have.

Having used many different web frameworks in many different languages, Mojolicious is by far my favorite.

It's super easy to get started. The documentation and community are incredibly helpful.

Mojolicious has many powerful built in tools, but it is easy to replace those with something else or work outside the framework when you need more flexibility.

Just to be pedantic ;)

var creates variables that are function scoped. my creates variables that are block scoped.

let in JavaScript would be pretty much the same as my.

Both are good things as they prevent typos from being new variables.

I'm a huge fan of Perl, and I've been playing around with Perl 6. The transition had been pretty smooth, and other than a few minor syntax changes (e.g. "." for method calls instead of "->") it feels the same.

Having said that, there is a lot more to Perl 6 than what comes baked into Perl 5.

The transition is a lot more like C to C++, where you could just use a C subset and be immediately productive.

Perl 6 has given me basically all the things I wanted changed in Perl 5 (function signatures, everything is an object, built in REPL) plus a whole bunch of stuff I didn't know I wanted but now love (gradual typing, crazy powerful type system, amazing out of box CLI argument parsing).

With Inline::Perl5 you also have access to all of CPAN.

Performance isn't quite there yet, but for the stuff I use it for (one off scripts, reports, personal CLI tools) it's been great.

Suggesting surgery is dangerous advice.

The "vast vast majority" of people that regain the weight in those studies are likely to be those who are the most prone to do so, and this can also be interpreted that structured weight-loss programs don't work: http://www.nytimes.com/1999/05/25/health/95-regain-lost-weig...

Look AHEAD: 8-year results (nearly 40% of participants who lost >-10% of initial weight at year 1 maintained this loss at year 8): http://www.obesity.org/obesity/news/press-releases/look-ahea...

You are correct, that it is impossible to track your calories everyday, for every meal, for the rest of your life.

If your diet takes work, or requires special foods (e.g. Nutrisystem), you'll eventually stop doing it and it'll fail.

To lose weight you have to make permanent lifestyle changes. Stop eating junk/processed food, rarely eating out, learning to cook, and eating primarily healthy foods.

I know this is anecdotal, but I know a dozen or so people in my life that have made lifestyle changes to their diet have kept the weight off for 10+ years. And they are the vast majority of people I know who have lost a significant amount of weight.

They didn't join any weight loss programs, so I don't know how a researcher would ever find statistics on them.

No sugar, No grains. Cutting back on mindless between meal snacking and also quit drinking beer/wine every night.

Basically just that. I'm down 20 lbs and still losing weight and it's been a breeze.

No additional exercise or calorie counting. (Though I was already walking a couple miles everyday).

Actually the first couple weeks were awful as I was kicking the sugar addiction. I didn't lose weight during that period since I was over eating other foods to compensate. But I didn't gain either and I was eating basically as much as I wanted without trying to feel stuffed.

Once I got used to not eating sugar, cutting back on my eating was easy. I didn't have the hunger pangs I used to, and I often have to remind myself to eat at meal times. (Which is crazy for me since I'm a glutton).

I still drink from time to time, and I haven't been crazy strict with it after the first couple weeks, but I'm still seeing great results.

Google NSNG and Vinnie Tortorich, he has a pod cast about this stuff. Very down to earth advice.

It's fashionable to declare Perl dead, but the truth of the matter is Perl is still everywhere.

Often in places like automation, or gluing disparate systems together.

While I know the TIOBE index has its flaws, Perl is consistently in the top 10 and has maintained that level of popularity for 20+ years.

With a history like that many critical systems are going to have a Perl dependency somewhere which means companies are going to need Perl developers.

This release contains fixes I submitted, and I would like to call out how welcoming and supportive the Perl 6 community was during the process.

Also, the fact that Perl6 is written in Perl6 made contributing especially easy.