daotoad

I graduated in 1996, we didn't do any of the work related stuff. We learned algorithms, datastructures, programming in imperative, OO, functional and declarative mode, numerical methods, discrete maths, operating systems, computability theory, and all the CS stuff.

SDLC is one of those things that every company seems to do a bit differently. Even if you are the GOD of SCRUM THEORY AND PRACTICE, most likely you'll wind up on a team that is kinda vaguely following scrum. Or more likely they've got a fish-ladder process with lots of little waterfalls that they call agile. Good luck effecting change, especially if you're straight outa school.

At best Agile methods provide an epistemology for project planning and estimation. At worst, it's a bunch of behaviors to mimic and terms to incant to justify bad or lacking processes.

I prototyped this sort of thing for an 8051 based project I was working on where we had more RAM and external EEPROM space than we really needed, but were regularly having to go back and grovel through the code looking for optimizations to make things fit in code memory.

The important thing to know is that 8051s have separate CODE and RAM address spaces. (Actually the RAM is divided up into multiple flavors too: direct, indirect, external and bit addressable.)

It turned out it wasn't worth the overhead. The interpreter and ancillary bits took up too much space and slowed things to a crawl. It was generally easier to rewrite sections of the code in a way that made the compiler and optimizer happy. By various techniques I managed to reduce the footprint of the system code by at least fourfold after a number of refactorings. The application kept needing new features, so it always barely fit in 16 code address space (some of which was already consumed by the bootloader).

While it is probable that some will dope in the clean league, a simple matter of instituting lifetime bans and reclassifying any and all records held by an athlete would put a strong disincentive.

As to your unsupported statement that all the fame and prestige will be associated with the clean league, that is a matter of marketing. If there wasn't a market for doped up, super-humans athletes professional sports would be very different. Look at WWE, it's not even really a sport, but it takes in half a billion dollars a year on the promise of watching steroid guzzling guys throw each other around.

For many people the problem with PED is the dishonesty, the unfair advantage it gives a cheat. But when the stigma of cheating is lifted, all that changes.

A more likely outcome is that fans of some sports would shun PED and unlimited league events, others would see it as a natural extension of their attitudes about competition.

https://www.wired.com/2012/09/sports-and-doping/

It's simple, have two leagues.

1. Human performance only - no drugs, no implants, no performance boosts. 2. Unlimited league. Take all the drugs you want, when we have them, install new muscles, cybernetic implants, whatever. Go wild.

This way, the real purists, who want to push the envelope of human capability get to do so without having to compete with dopers.

AND

High dollar/prestige sports will fund new and interesting areas of biomedical research. It will be like indy car racing for human bodies.

I don't think it was just the "harmless claim" that was the issue. Many of his points were objectionable if not outright offensive. The obvious example of an offensive claim is that women are more prone to be neurotic. Also, can you really assert that you've checked your biases if you claim that people who agree with you (conservatives) are "pragmatic" while those who disagree (liberals) are "idealistic". I'm sorry, but that is complete and total BS. It's not hard to see that there are pragmatists and ideologues in both the liberal and conservative political movements.

As a white male engineer, I will tell you thing the that most white dudes like me fail to understand about micro-agressions- and the document was chock full of them-is that they are not really significant when they only happen once, in isolation, it is the constant, droning repetition of them that makes them harmful.

Asking someone where they're from isn't offensive when considered in isolation. But if 90% of the white people you meet ask you this immediately, while it comes up only occasionally or late in the conversation when meeting other people, it makes you wonder.

One thing my mixed race friends get asked a lot by white people is "what are you?". At first I found that hard to believe, but I've seen it happen over and over again--random chitchat at the park with a nice lady who stopped to pet my dog; for some reason she has to ask my friend "what are you?" She's too nice to say "not racist, how about you?" or anything harsh in response, but it makes my blood boil.

Imagine being expected to defend and define your presence everywhere you go.

So, yeah, the idea was harmless. The presentation was part of the constant barrage of gatekeeping behavior that women and people of color are sick of dealing with. That's why it's offensive, that's why people are angry.

Too bad the nifty techno-in-a-can synth diddling in the video drowns out the inventor talking about his technology.

While I can understand Google deciding to fire the author, he's embarrassed the shit out of his company in a very public way, I think it would be sad if they do.

The dude has some serious misconceptions about the world and people, but I think his heart is in the right place. He's working from some bad assumptions and has come to bad conclusions as a result. It's classic Garbage-In-Garbage-Out.

I'd really like to see the Goog take this as an opportunity to really reach out to this guy (and hopefully all the other software bros who give enough of a fuck to pay attention) and help him understand better. If they can get through to him, they will have a very persuasive proponent of reform on their hands.

Also, treating this guy with respect and not firing him outright will demonstrate that open conversation about important issues is allowed at Google.

And, in case it sounds like I agree with Mr. Bro Grammer, "wimmins is soo emotional", I think the gentleman needs a solid walloping with a clue-stick.

Good idea for a website, should be able to get you some nice revenue from intermittent visits. You probably want to focus on financial services for your ads.

I'm not going to say anything about your numbers and your models other than, without the ability to see how they looked at previous crashes, it's hard to see if the site is useful. To the innumerate masses and emotional investors the flickering numbers are persuasive enough. So they really don't matter.

On the bad side, your UX is god-awful. Use an oldish, slightly crappy monitor to look at it and you will discover that your background is indistinguishable from the foreground. The top bar of the box completely disappears, too. Also, a row of buttons is NOT a good tabbed interface--there is no indication that clicking on "Market Volatility" is going to reload all the content below the row of buttons. Maybe make actual tabs, at least make that stuff a distinct box.

This could be a nice little side product to make you some extra money. Get some GA on there, and slowly add features. I think a bit of interactivity and the ability to customize the predictive models through some drag and drop could actually make the page sticky and get people coming back.

Perpetual intermediates exist in every field, many of them with far more nuance than any mere programming language has to offer. The way to extract productivity from these people is the same in software development as it is in any endeavor: leadership.

Good leaders identify and propagate conventions that can keep their teams functioning in a complex millieu.

You can't get rid of the irreducible complexity of any system. You can only move it around.

In my experience, if you use an expressive language well, you can fit the code to the problem domain in a way that better communicates the underlying approach you have taken to solving the problem.

Relying on strict, small languages, like Java, means that you gain a consistency of syntax by sacrificing flexibility.

I've seen monstrous turds written in many languages, the problem in all these cases was poor or absent leadership.

You aren't alone in thinking that.

http://blogs.perl.org/users/zoffix_znet/2017/07/the-hot-new-...

https://github.com/perl6/marketing/blob/master/TablePosters/...

It's still pretty new, so the library infrastructure sucks (but getting better every day).

I'm only peripherally involved in the community, but at this point, it seems people are using it primarily for small utilities and such.

So do you like small tools or having everything built in (like a REPL)?

It sounds like you are justifying an emotional attachment rather than making consistent arguments.

Now, there is nothing wrong with having an emotional attachment to a language or other tool, as long as you know it for what it is.

Python is a great language and has some really nice features, it's C extension system is miles better than Perl 5's horrible mess called XS. But to me, using it feels like wearing my shoes on the wrong feet, I really prefer Perl 5.

From my experience and from listening to colleagues, Python has one edge on Perl 5. Perl 5 and Python have very similar tooling abilities. Long term maintenance of large systems is pretty much the same. Python has the edge in ability to find and hire qualified people because the community has done a better job articulating Python's strengths and recruiting new people.

Come up with a style guide and stick to it. Failure to do that with any language, no matter how restrictive, leads to messy code.

It doesn't matter which way you unpack your args unless you are trying to do something fancy (the sub 1% cases). Just pick one.

Hell, it's easy enough to make a script to rewrite multiple shifts into destructured list assignment or vice versa.

The significant part of argument handling in Perl5 is that @_ is a list of aliases to the arguments. You usually see add1 or add2 style argument processing because nice named arguments that are a copies of the function parameters.

add3 shows how to access the aliased arguments directly.

  # break the aliasing of @_ and make undef into 0.
  sub undef_to_zero { @_ = map { $_ // 0 } @_; }

  sub math_stuff {
    # call with identical @_
    &undef_to_zero;
    # Do math without undef warnings.
    my $sum = 0;
    $sum += $_ for @_;
  }

  # Alter all arguments in calls by repeating them
  sub fatten {
    $_ = "$_" x 2 for @_;
  }

  $foo = "abc";
  @bar = ( 1, 2, 4 );
  foo($foo, @bar);
  say $foo; # abcabc
  say for @bar # 11
               # 22
               # 44

Perl 6 is designed to be a large, feature rich language that can be learned and used incrementally. The intent is that, like users of natural languages, Perl 6 practitioners gain fluency and nuance in their expression over time.

So, if you want to learn Perl6, don't worry about writing "baby talk" Perl 6. Write something that works and solves your problem. Later on you may learn that there are multiple other ways to express the same ideas you wrote already. Maybe one of them better expresses the heart of your algorithm, then you update your code.

Now, you may think, how the heck am I going to maintain code written by a bunch of people at different phases of learning Perl6?

The Perl community has responded to this challenge by putting a huge amount of work into writing excellent documentation. Perl6 docs are readily searchable and carefully indexed. It's a big, new language with lots to write about, so the docs are not yet complete, but they are already fantastic and keep getting better.

So, please, just pick a problem to solve and jump on in. The water's fine.

I think the real dark pattern here is the stupid animated scribbles under the section headers.

WTF?! Is this 1997? Why don't you bring back the blink tag while you're at it!

Sigh.

So, I am a white dude who was pretty skeptical about the whole microaggression thing. But I changed my mind.

My girlfriend is biracial and just watching how strangers interact with her taught me a lot about the state of race relations in this country.

Microaggressions (I am going to abbreviate this as MA) are more like micro-transgressions. In the vast majority of cases, the people who commit MA are not seeking to hurt the recipient of the MA, they are likely trying to be pleasant and friendly. But there is something about the interaction where the person expresses a subconscious bias that the target is not normal.

A great example, is the question "What are you?" How often are you asked this question? Me, I've never been asked this outside of Halloween. My GF gets this question a lot, at the grocery store, at the dog park, etc. Why? What does it mean? Why is it hurtful?

The questioner never means anything bad by the question. It's honest curiosity.

Based on the conversation that follows (a nice chat about our respective ancestries) and the fact that I never get asked this question, they are really asking, "are you black, Pacific islander, asian, or what?" but have learned that that is a rude question.

Why is this an unpleasant experience? It is "othering". Yeah, what does that mean? Well, it means that it is inherently exclusionary. It means that the asker of the question sees you as fundamentally different. And not in a good "let's celebrate our differences"-way, but in a hidden-deep-in-our-limited-monkey-brain "is this person safe" kind of way. It means "are you going to mug me" and "do I have to worry about saying something racist that my white friends would give me a pass on". It means "Are you one of us?" with the presumed answer of "no". For most of us, all of this is subconscious.

People who get asked "what are you?" regularly know what the implicit questions are, even if the person asking them doesn't. They questions feel aggressive, but they aren't outright, in-your-face, aggression.

Ask yourself, honestly, when you meet a white person who speaks with a local accent, how soon do you ask about their heritage?

He's got his routing handled. You may wish to 'root' for him, however.

People think Perl code is unreadable and mysterious because the language design philosophy is different than other programming languages. Most languages strive for a limited, orthogonal set of built-ins and features without any repetition. Most languages enforce opinions about how things like OO and function calls are going to work.

Perl is designed to be maximally expressive. It is designed to be instantly familiar to someone who writes shell script, uses sed and/or awk and writes C for Unix environments. If you don't have this background, it can be a lot to absorb.

Here are some big things that Perl outsiders find troublesome at first glance:

1. Sigils are mysterious and scary--other languages don't have them. In practice, they're rather nice--they distinguish between functions and variables. They act sort of like a minimalist form of hungarian notation.

2. Built in regexes. Regex syntax is dense and messy. Putting it right in the language makes them easy to use. It also can make things hard to read. Perl didn't invent regexes and tt hasn't stopped most languages from implementing regex libraries. That's why Perl offers the expanded syntax that makes it easy to document complex regexes.

3. Special variables - $_, @_ are odd enough, but when add in the whole panoply from perlvar, it's pretty gross. In reality you really only need to know a few ($_, $@, @_, and $! are the only ones I use regularly), but they are terse and must simply be memorized.

4. Function calls in Perl are weird. Most people use one of the two common forms of argument unpacking that give you pass by copy semantics, but you can also pass by reference. Once you get the hang of it, it's not that complicated, but it is different and can be more than a little confusing for newbies.

5. List flattening. When you call a function like so: foo( @bar, %baz, $qux ), it gets one big list of arguments, the members of @bar and %baz get expanded. It's sort of the opposite of destructuring on assignment.