Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three Tribes of Programming (2017)

josephg.com

Post reply on HN
Print view View original

51–60 of 123 posts

Re: Three Tribes of Programming (2017)

#51

Post by CodeMage »

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 this. It's in the same vein as the blog post, but it addresses the only aspect I was truly uncomfortable with: the word "tribe" implies exclusivity, whereas I tend to think of myself and other devs as points in the triangle whose vertices are these tribes.

Re: Three Tribes of Programming (2017)

#52

Post by marcosdumay »

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'…

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 Haskell is one of the greatest languages for handling "Oh, sorry, actually..." requisites, and Perl one of the worst.

Re: Three Tribes of Programming (2017)

#53

Post by all2 »

ummonk wrote: post #7

Good article, though Ada is misplaced there. It is more of a maker’s language. It just has a formal proving add on (SPARK) available to test correctness because of its use in mission critical software where correctness really really matters. People who love Haskell, lisp, etc. despise Ada.

> People who love Haskell, lisp, etc. despise Ada.

Why?

Re: Three Tribes of Programming (2017)

#54

Post by dllthomas »

marcosdumay wrote: post #52
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'…

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 small.

Re: Three Tribes of Programming (2017)

#55

Post by dllthomas »

proverbialbunny wrote: post #43
hinkley wrote: post #3

> You are a maker. You build things for people to use I am a maker. I build things for people to use and maintain . This puts me at endless odds with the hackers. All three groups suffer from Novelty Seeking and Risk Taking (aka Adrenaline Junkies), but the hackers seem to get it the worst. My hatred of tools that fall apart the third time you use them goes back to childhood. I don't want to put my name on any of tha…

>I am a maker. I build things for people to use and maintain. So you're dev ops? Jokes aside, do you really have a passion for maintaining projects? This is something I deeply struggle with and any advice on the subject I would be deeply grateful for. I thought I could deal with it and enjoy a project in the long run if it had no bugs, so I worked on some of the code the internet runs on, where even putting in one bu…

You don't need passion for maintaining projects to have compassion for the people who need to maintain your projects (whether or not that's also you).

As you point out, though, some code actually doesn't require maintenance. But at the same time, that's not always the code you think.

Re: Three Tribes of Programming (2017)

#56

Post by jcadam »

all2 wrote: post #53
ummonk wrote: post #7

Good article, though Ada is misplaced there. It is more of a maker’s language. It just has a formal proving add on (SPARK) available to test correctness because of its use in mission critical software where correctness really really matters. People who love Haskell, lisp, etc. despise Ada.

> People who love Haskell, lisp, etc. despise Ada. Why?

I love Lisp, and I don't despise Ada. I mean, I would never pick it over Lisp for a new project (well, I can think of one or two very narrow niches where it would probably be the most appropriate choice), but I would rate Ada above, say, Java, C++, and Go.

Re: Three Tribes of Programming (2017)

#57

Post by 0xdeadbeefbabe »

Quekid5 wrote: post #21
hinkley wrote: post #3

> You are a maker. You build things for people to use I am a maker. I build things for people to use and maintain . This puts me at endless odds with the hackers. All three groups suffer from Novelty Seeking and Risk Taking (aka Adrenaline Junkies), but the hackers seem to get it the worst. My hatred of tools that fall apart the third time you use them goes back to childhood. I don't want to put my name on any of tha…

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…

What is the deal with maintenance engineers thinking every engineer ought to be one? Can't you agree it takes all types or is there something about maintenance that preempts such thoughts?

Edit: Maybe I should go around pretending hackers and poets have the moral high ground.

Re: Three Tribes of Programming (2017)

#58

Post by Legogris »

thethirdone wrote: post #9
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 agree with your three problems, but only if problems means hard roadblocks to achieving your goal. Much of programming is encoding what you want to computer to achieve and is therefore a rather long process, but not necessarily hard. Precisely specifying how a GUI should look has a substantial amount of necessary complexity, and writing that out doesn't fall into 1, 2 or 3.

You could also argue that that is a separate thing from programming. I don't at all mean to be to be snobbish here, just that it's useful to draw the line somewhere between there. Modeling is not programming. Architecture is not really, either, even if the process can involve programming.

Re: Three Tribes of Programming (2017)

#59

Post by ergothus »

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'm totally stealing this for teaching to my grad students, it's a much better way of stating what I try to stumble through each semester talking about "programming as communication"!

Re: Three Tribes of Programming (2017)

#60

Post by crimsonalucard »

pizlonator wrote: post #47
crimsonalucard wrote: post #8

Earlier quoted context omitted.

It is an implementation detail when you go to the extreme. Most people are not segmented this rigidly though so of course they worry about execution as well as the high level mathematics. But most of the high level math and designs give a high level view of everything. Category theory and type theory don't fit cleanly with assembly language (the implementation detail). Additionally at the very fundamentals of mathema…

To be a mathematician computer programmer, you don’t have to use the Church-Turing mental framework all the time. Sometimes it’s useful and sometimes not.

Of course you don't. I never said you did. In fact I would argue you never think about this isomorphism 99% of the time.

I'm just saying that a big portion of the math doesn't describe the real world implementation details.

As I said the Church side of the theory doesn't have a real world machine equivalent. We have machines that move things and save things but we don't have a physical machine that represents the concept of a function call. What we instead have is a Turing machine that emulates a function call, not a true simulation of it.

Post reply on HN