Three Tribes of Programming (2017) • Hacker News Board

Re: Three Tribes of Programming (2017)

#61

Post by NoodleIncident » Fri, Sep 06, 2019, 9:40 PM UTC

jandrese wrote: post #48

AnimalMuppet wrote: post #32

> I did a Haskell short course late last year and I challenged the main instructor. I told him "this is all well and good, but I bet I can still make useful software using my practical languages faster than you can". He said no way - using haskell he was convinced he could implement anything I could implement, faster and better and with less code. We didn't test the claim - but I still wonder - is he right? OK, here'…

Seven lines is even a bit much. You could do it all on the commandline if you don't mind a bit of ugliness, and all Perl programmers should be used to some ugliness. perl -ne 'if (/^(\d+)/) { print $1, "\n" }' Put the list of input files at the end of the line.

    grep -oP "^\d+"

Re: Three Tribes of Programming (2017)

#62

Post by stephc_int13 » Fri, Sep 06, 2019, 9:45 PM UTC

I've come to almost the same conclusions as the author.

- The first tribe is mostly coming from Maths background, their favorite performance measure is the big O notation.

- The second tribe is coming from Physics/Engineering background, their favorite performance measure is expressed in SI units, most often a duration.

- The third tribe is coming from everywhere else, and their favorite performance measure is customer satisfaction, or in other words dollars.

Re: Three Tribes of Programming (2017)

#63

Post by AnimalMuppet » Fri, Sep 06, 2019, 9:50 PM UTC

dllthomas wrote: post #54

marcosdumay wrote: post #52

Earlier quoted context omitted.

Haskell is actually one of the greatest text handling languages out there, and will beat Perl5 on most such tasks. (Perl6 was made similar to Haskell, so none would beat the other.) This one contrived example does favor Perl, and will beat Haskell by a small margin. But as soon as the user says "Oh, sorry, I was mistaken, I needed the number and the next letter" or something like that, Haskell is on top again. As Has…

Eh... As long as the "actually..." only needs a small change to a simple regex (as in your example), perl probably wins the "actually..." game as well until you pull in enough libraries that the Haskell looks a lot like the perl. It's when the regex starts getting overcomplicated and the Haskell breaks out parser combinators that Haskell probably moves into the lead. As you say, though, the margin perl maintains is s…

I think marcosdumay's claim is that Perl is less editable than Haskell. That's arguably true, though I'm not sure that editing a simple regexp in a simple script actually shows the issue.

Re: Three Tribes of Programming (2017)

#64

Post by arcticbull » Fri, Sep 06, 2019, 9:51 PM UTC

jaaron wrote: post #2

This is fantastic and surprisingly close to how I tended to explain computer science to students and graduates: In Computer Science, there are 3 kinds of problems: 1. The problems that Math gives you: algorithms, data structures. These are the problems you think you're going to solve and sometimes you do, but often we just need a few really smart programmers to solve this and the rest of us can just use those solutio…

I like to remind largely junior engineers I work with that we're basically Dell. We're system integrators. We take the bits that other people have made and glue them together in a fancy box. If they start doing computer science they need to stop for a second and ask themselves if they're really sure they should be doing computer science in case someone else already has and they can just leverage what they've done.

The focus for me is really building appropriate abstractions over the work I do so that people can focus on improving only the vertical slice they need to.

Re: Three Tribes of Programming (2017)

#65

Post by yesbabyyes » Fri, Sep 06, 2019, 9:52 PM UTC

jandrese wrote: post #48

AnimalMuppet wrote: post #32

> I did a Haskell short course late last year and I challenged the main instructor. I told him "this is all well and good, but I bet I can still make useful software using my practical languages faster than you can". He said no way - using haskell he was convinced he could implement anything I could implement, faster and better and with less code. We didn't test the claim - but I still wonder - is he right? OK, here'…

Seven lines is even a bit much. You could do it all on the commandline if you don't mind a bit of ugliness, and all Perl programmers should be used to some ugliness. perl -ne 'if (/^(\d+)/) { print $1, "\n" }' Put the list of input files at the end of the line.

  grep -Eo '^\d+' file

Re: Three Tribes of Programming (2017)

#66

Post by novok » Fri, Sep 06, 2019, 9:59 PM UTC

sepen77 wrote: post #45

Quekid5 wrote: post #21

Earlier quoted context omitted.

At the risk of just jumping on a single point: > I build things for people to use and maintain. Maintenance. Maintenance. Maintenance. That's the key. It is the lack of that mindset which is killing our home world. Ultimately, it's just expression of not having to pay for your externalities. It also kills software dev. If software devs were actually held to account for their legacy (software, hah), then we'd have a l…

In context of this, I've always been thinking that software engineers should be held way more liable -- like those of the physical engineering disciplines. In order to enforce good software engineering practice, there must be either incentives or disincentives (carrot or stick) that have clear consequences on the engineer himself/herself. Otherwise there is nothing stopping them from producing bad work. It may be uni…

If you create liability traps, the price of everything goes up and many things do not get made at all.

It's like saying that tents shouldn't exist and people shouldn't use bicycles even though they are great tools for certain jobs.

Nobody wants to pay for space shuttle levels of software engineering. It costs a lot in labor time to produce less results.

Re: Three Tribes of Programming (2017)

#67

Post by harimau777 » Fri, Sep 06, 2019, 10:42 PM UTC

Very cool article, but also a little depressing. I probably fall mostly into the "poet" camp and it often feels like the industry is setup to beat people down who approach code that way.

Re: Three Tribes of Programming (2017)

#68

Post by [deleted] » Fri, Sep 06, 2019, 10:44 PM UTC

bakery2k wrote: post #41

The article claims that most professional software engineers are "makers" - people who build things for other people to use. I would put myself in this category, but I really struggled when I was a professional software engineer because the job seems to be set up for "poets" and "hackers", not for "makers". Once I've finished building something, as a "maker", I want to be involved in communication with customers and…

[deleted]

Re: Three Tribes of Programming (2017)

#69

Post by Bekwnn » Fri, Sep 06, 2019, 10:59 PM UTC

tolmasky wrote: post #37

I think this is a good article, but ironically I think all three tribes would actually describe themselves the same way many times (whereas this article implies they'd describe themselves, or what matters to them, differently). To use an example from the article, I think Jonathan Blow would absolutely argue that he wrote his own game engine because it was best for his user . Whether you agree with him or not, he is w…

Re: Jonathan Blow, I don't think it's a stretch to say different/better tools can have a profound effect on the industry and resulting games as a whole. As someone in games, quite a lot of software has had far-reaching impact that influenced games on a noteworthy level. Speedtree, Zbrush, and the substance package have basically defined modern AAA art assets. And while the major public engines have had a profound impact, even things like Source mods, RPG Maker, and Game Maker have had a profound impact in terms of enabling development of breakout indie hits or introducing people to game development as a whole who are now in the industry.

So I don't think it's a stretch to say a performant alternative to C++ with a game engine out of the box could have an impact which has broader reach than speedier development of his next game.

Re: Three Tribes of Programming (2017)

#70

Post by sudosteph » Fri, Sep 06, 2019, 11:07 PM UTC

rogueSkib wrote: post #33

Fourth Camp: You are a tinker and a smithy. You build tools for other developers to use. * Source Code: Your code is clean enough for you. Your top priority is thorough documentation and intuitive API design. * Execution: Critical around bottle necks, like large batch processing and build times, otherwise it doesn't matter. Iterate and optimize based on feedback from your devs. * Correctness: The program should funct…

I was going to post a comment like this if I couldn't find one! As a DevOps-type engineer who writes mostly internal tooling - I really couldn't relate to any of the 3 camps that the author mentioned, but I can relate to what you wrote. Tooling for developers and opearations / SRE types in general all follow a similar paradigm to what you mentioned.

I'd add to add: Fav languages: Whatever is already installed and easy to deploy and maintain/debug on your target system. For linux systems, this might mean Python, Bash, Go.

Additional Hangouts: Forums about AWS/GCP/Azure tooling, Hashicorp projects, Config Management Software projects (ie, ansible)