How We Grow Junior Developers at the BBC - <AUTHOR> https://medium.com/bbc-design-engineering/how-we-grow-junior-developers-at-the-bbc-dc3054f7e390 <comment><USER2> I work at a small Japanese company with only two developers; myself and a junior developer (also American) we brought on as my assistant a year ago. He came on with little to no development and technological experience but an incredible work/study ethic and a willingness to learn, which are both MUCH more important to me.

The skills can be learned and refined over time, but the fundamentals need to be there; if a developer doesn't have the right mindset or ability to learn, then they're never going to grow, no matter how much you poke at them.

One issue I've been fighting (with myself) is knowing when to criticize and knowing when to let him go; I err toward the latter a lot, especially technically, but lean toward giving advice sessions or examples when it comes to communication/professional growth skills. The reason I do this is because it's much, much easier to refine technical skills than it is to refine personal skills... and the personal skills are equally as important at a small company when time is precious and you're working directly with other people who are also under heavy loads and pressure.

I bring this up because I was surprised to see zero mention of independence as a prized quality after the author commented that he did NOT feel like a cog in the machine at the BBC. There is, I feel, a fine line between needing to be told what to do every time and being able to make the right decisions on your own.

The latter quality -- reasoned independence -- is something I think every work environment should foster in its team members in order to have a team that respects and can support each other. Teams fall apart if members need to be told each and every thing they're supposed to do: members will either grow to hate that or will become mindless minions; the team falls apart when the order-giver is no longer there; over-communication becomes an issue and more time is spent in meetings or replying to 100+ e-mail chains instead of developing things for customers.

I rarely see much talk about this kind of growth in developers here though... and it makes me wonder if I'm misguided in placing so much importance on this concept.

<comment><USER3> Currently have a junior dev on the team that asks way too many questions, most that can be easily googled. How do we push him in the right direction to become more independant.

<comment><USER2> Your particular handling of him will depend on his personality and relation to the team, but one way I've found to handle this is to sit with him on a few questions and walk him through the most basic levels of your thought process as you think of queries and Google them, select results, etc. This way you're "teaching him to fish" so that he can use that methodology in the future.

While it may often seem simple to "just Google it," it can be difficult for people to come up with appropriate queries and weigh results, especially in new/unknown contexts.

A lot of the time we have ready answers if other people ask us questions because we're actively ready to attack and criticize to get an answer, but we're more reluctant to do that with ourselves. So if the teaching approach doesn't work, then another way is to ask him to list up the questions he has, give it 10-15 minutes, then review them himself to see how he would answer them -- the idea is to give him some time to "reset" and get a fresh perspective.

</comment></comment></comment><comment><USER4> One thing about junior devs is the level of skill varies greatly. Where I work there's a guy who is nominally a junior dev, but he already knows everything the senior devs are expected to do. If he was an average guy there'd be a lot more handholding, but somehow with barely any hiring process (he was a friend of a friend) we lucked out. I'm wondering whether management will be smart and pay him like a senior dev so he doesn't leave as soon as he finds out he could be making a few hundred grand instead of a few tens.

One major downside of this kind of variation is managers think they can somehow repeat the trick. If we just make the hiring process hard enough and shove enough candidates through, we can pan for those elusive 10x guys. It also makes people think that 10x guys are a thing like a gold nugget in the river, rather than the outcome of a long process of maturation in an appropriate environment.

<comment><USER5> Yeah I've kinda been that guy. Went from university straight into a green field project that allowed me to grow very fast and I was smart and competent enough to handle it. I knew the project inside and out and everyone liked me. They billed me out at $250 and paid me $40. So I switched jobs after 1.5yrs for a 40% raise. Then the same thing happened, so after 1yr I got another job, also through a guy I had worked with who had seen I was good, for another 15% raise. It's funny how a company can get hung up on relative pay-raises instead of considering actual value added.

<comment><USER6> I'm that guy but instead of leaving I hung around, god knows why.

After three years, I'm interviewing and getting offers of about 60% salary increase.

From £32,200 -> £55,000.

</comment></comment></comment><comment><USER7> It somehow always saddens me to read that.

Most devs I know started at a small company who didn't "grew" them at all.

I worked 7 years at a small company and never got any mentoring or external education etc. while the "good" ppl I knew from university got jobs at big corps and got even better because they got "grown" right.

Who already has is given.

<comment><USER8> Same here. Started as junior (with 7 years programming experience from school) with a few other juniors at a company working on a new product without any senior developers anymore. It sure was a little rough sometimes and we sure made our fair share of errors and technical debt, but it was an amazing experience. And the product still works fine today.

So with a motivated team and some autodidactic learning you can still get very far! Especially since Google and Stackoverflow.com are at your disposal.

<comment><USER7> It didn't even occur to me that I could educate myself in that time.

I started doing it after I was 9 years in.

<comment><USER9> So you basically sat on your ass and said "somebody teach me"? No wonder that your colleagues from university got so much better.

I never got much help from other people. In the beginning, I didn't have _anybody_ interested in computers around me at all, yet I managed to learn programming. Then, when I started studying IT and switched to Linux, and I didn't have anybody to systematically learn working with unix from. This happened when I didn't have an access to the internet, and we had very little learning material published (first half of '00 decade), so it wasn't even possible for me to ask a question on StackOverflow or something.

And then the pattern repeats a number of times.

It's not _mentoring_ that helps people grow. It's _learning_. It can be done with a teacher/mentor (and in fact it's easier in a number of fields), but it doesn't _require_ one. Don't blame others for your own idleness.

<comment><USER7> Point wasn't that I was lazy, point was that I had the impression after university I'm a dev and get a job and work.

<comment><USER10> That's a great admission, to admit that to yourself let alone in a pseudo- public environment shows growth and maturity so many tech people often lack

<comment><USER7> I want to be good in what I do, not just think I am good.

Many people can take enough from simply feeling better than everyone around them.

On the other hand I often feel bad about myself, which isn't good either.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> > I worked in an all-senior team once. Nobody admitted not understanding > something. Everyone wrote overly-complex code just to 1-up each other

Sorry to hear about that experience. Those aren't senior developers. There's no room for learning when you think you know everything. Senior developers mentor, simplify, document, and admit when they don't know the answers.

<comment><USER12> > Senior developers mentor, simplify, document, and admit when they don't know > the answers.

Sadly this is far from my experience as well. It's likely a few toxic work environments.

Not to hijack your comment but I would like to offer a specific example I've seen of toxic behavior from senior developers. Many don't actually read the questions you ask of them or trust your knowledge. It's very similar to attitudes I see on Reddit, HackerNews, or StackOverflow:

"Hey I'm having a bit of trouble getting this to compile / run / there's this weird error I'm encountering. I read the documentation and based on that tried X, Y, and Z, but none of those solved my problem / my problem appears somewhat different." (Where each of X, Y, and Z are somewhat long explanations of what was tried).

"Did you try X?"

"Uh yes I did" (then to be polite I repeat my explanation of doing X)

"What about Y?"

You see what I mean. Especially in text, I find that some senior developers can't be bothered to _actually read what someone else said_. So if you're worried that you're a poor senior developer, I recommend you actually try and read what your younger colleagues say and ask of you. And especially trust that they are being honest with you. Don't assume that someone is lying or that they're wrong on the first pass - it's condescending, frustrating, and usually a waste of time. If you hired someone in the first place, you should be allowed to assume a bare minimum of competency and if for some reason that fails, you can always question them after the fact. I think it's a result of our engineering mindset to assume absolute idiocy in every case and then work our way up, but I think it's more productive (and especially better leadership) to assume that your subordinates know what they are doing.

In the context of an online forum like this, I think it's best to do the opposite: assume idiocy and work your way to competency - simply because we are all anonymous and don't know each other. The actual workplace should be treated differently though. People always perform better when you put your trust in them.

<comment><USER13> Maybe I read your post wrong, but your post seems to complain that Senior Developers don't believe some Junior hires have minimum competency if they are unable to compile a file.

That seems like something a Junior Dev should have mastered during their educational period.

<comment><USER14> Then you're not senior enough to know enough of the unique problems that come from trying to compile things, especially for embedded devices.

One of the non-embedded cases is compiling boost on a visual studio machine for wrapping python which can be its own special kind of hell. I've seen at least one very respected principal developer wholly screw this up. I can write for hours on those kinds of problems and how to solve them.

</comment></comment></comment></comment><comment><USER15> Lots of good stuff in this, but i have a couple of significant nits.

First, paired programming is a great way to help a junior learn. But it's dependent upon their desire, i do it frequently with one whose eyes glaze over when i explain what i'm doing and i know when they start surfing the web while i'm implementing.

But otherwise paired programming is just a great way to slow me down.

Secondly, the open floor plan they described is a clear disregard for the productivity of individual software engineers. Maybe the author never experienced the difference, but it's significant.

<comment><USER16> > Secondly, the open floor plan they described is a clear disregard for the > productivity of individual software engineers. Maybe the author never > experienced the difference, but it's significant.

Actually, I have. I've worked in two small digital agencies where the devs were in their own office. I didn't like it. It was too quiet for me and I felt like I wasn't allowed to talk to anyone. I concentrate better when I have background noise. Some of my colleagues have headphones, but I don't like to use them because I don't want to give the impression that I don't want anyone to interrupt me. I prefer people coming up to me to speak to me rather than sending me a message.

There's a very good historical reason why the BBC is committed to open plan offices and hot desking. Back in BBC Television Centre days (if I'm remembering correctly), it used to be that managers would have their own offices and the teams they line managed would be based in a completely different part of the building. Eventually, someone realised this is silly. There was a huge transformation of the corporation's culture, which brought about the existence of the BBC Values, and no one was allowed to have their own private office any more. Managers would sit with their teams, and people were able to just go up to other teams and chat with them, collaborate, etc.

It would go against the BBC Values if someone senior gave themselves a sense of greater self-importance just because they were a higher grade. No one should be told, 'You can't talk to me because your grade is too low'.

<comment><USER15> It's fine to put managers in the same area as their teams.

It's fine if you prefer to work in an open area.

But studies are pretty consistent that developers are more productive with fewer distractions. Not giving developers the option of private offices is underutilizing some of your most expensive resources.

<comment><USER16> True! I think a lot of modern workplaces are good at compromising on this. In our case, we don't have private offices, but there are quiet working areas that you can go to to work. Although these are sparse in our Salford campus, unfortunately; there's a lot more in the London buildings.

<comment><USER15> I actually work in an open floor plan. I have a great boss, coworkers, interesting work, the only thing I hate are the distractions.

In our case we have "breakout rooms", nominally for impromptu meetings but it's acceptable to camp out in them for a while if you need privacy/focus. But I can't drag my big screen monitor in them, or use them every day, so they are a very imperfect solution. If we added large screen monitors to them, and allowed engineers to camp in them most of the day every day, they'd be perfect. But then they'd be, private offices.

The last time I managed people, I had the company build small single person offices for them. If they needed to pairs or a bit, they had just enough room for that. If they needed a meeting with more than 2 people, there were rooms for that.

We never had problems with collaboration or communication, and this was before slack. Team members would email non urgent information to their team. Product managers would sit in your office to work out details of a new feature or bug to be solved. But if it wasn't urgent, they'd respect your need for focus.

</comment></comment></comment></comment></comment><comment><USER17> I train new technical hires at Fortune 500 financial institutions so this article struck a chord with me.

One of the key points that I leave my cohort with overlaps with the OP's point about fresh perspectives. The hires I'm with are up to speed with the newest languages, newest frameworks, and newest tools. I encourage them over and over to try to bring that knowledge into their roles.

</comment><comment><USER18> This is an exciting read for me as I start as a Software Engineer at the BBC on Monday!

<comment><USER19> Good luck with your job! What sort of languages/technologies will you be working with?

</comment></comment><comment><USER20> What they don't mention is the abysmal salary (£23,000~) they start you on. No idea why anyone would choose to work there.

<comment><USER16> I turned down a graduate contract in London for £30k, going up to £40k after two years, to be at the BBC. If you want to work at BBC D&E, you accept that you're not going to get a competitive salary. But in return, you get very relaxed and laid back working conditions. (Or so people tell me. I haven't worked at any other large software org to compare.)

Someone I know, who is now a principal dev, was previously a contractor for the BBC. He decided to leave contracting and join the corporation permanently. He's one of the most amazingly clever developers I have ever met.

(But yes, we'd all still appreciate it if we could be paid more.)

</comment></comment><comment><USER21> Isn't the BBC a company where the only senior positions are as a contractor, charging 3 times the amount of their permanent counterpart for much less hassle?

I am not sure if the author is trying to write a nice PR piece or is so inexperienced that he believes in all this corporate bullshit he's repeating. ^^

<comment><USER22> I'm not the author, but I recently joined the BBC as a software engineer and haven't found all that many contractors at all, the ones I have are in regular non-senior positions.

It may be the case for 'talent' and management of TV projects (for example), but in the tech departments - your assertion, in my experience seems to be far from true.

<comment><USER10> I've been here 14 years which is just about long enough to not be a newbie any more. I now plenty of contractors, most are useless. After 5 years one of the few good ones has taken a staff job.

We do seem to be getting better, the recent IR35 rules helped, but we still have contractors employing contractors. At a high level they're typically there to implement some bad idea and the fuck off so everyone can blame them afterwards.

<comment><USER23> One of your major contractors are the organisation that runs the TV and radio transmitters, Arqiva. An organisation absolutely bloated with middle management and contractors employing subcontractors.

The BBC would have been better off keeping transmission in-house.

<comment><USER10> Oh yes, we outsource many departments that used to be in house, from transmitters to cleaning, I was referring to contractors working alongside full time staff - usually because we don't pay staff enough to fill the roles with the right people.

</comment></comment></comment></comment></comment><comment><USER24> "I wanted to make sure that my first job post-university would be somewhere where I would feel happy and work not on my own, but with an agile team ..."

It's interesting that any young developer would regard the micromanagement that comes with agile as a plus.

<comment><USER25> > micromanagement that comes with agile

It's a sad day when the ideas behind the agile movement have fully become the Agile System (tm) in engineer consciousness. The word used to denote a style of working, not characterised by micromanagement or by a Scrum Master (tm, again) telling people what to do, but ironically by leaving behind dogma for a loose collection of principles that worked effectively for the team and the problem at hand. The word has been lost, though. Using the word 'agile' now evokes more derision than enthusiasm or excitement.

<comment><USER26> Curious why would one think agile is micromanaging?

<comment><USER27> Because Agile is seen as a set of processes, not a set of values. The new hotness is time tracking -- making developers accountable at a micro-level for how much time they spend at each step of developing a feature, enhancement, or fix. All of which will have been specified in the beginning-of-sprint planning meeting of course. Management likes this because to them it's like profiling and optimizing a program. Developers hate it because the numbers are BS and the planning is basically waterfall in miniature, giving them little opportunity to explore the solution space. Plus the data collection itself is panopticon-ish.

Agile was an attempt to sell basic (old school, think CSAIL not L0pht) hacking strategies to stiff-necked managers and executives under the rubric of making better software for cheaper. But managers and executives have their own set of values: measurability and predictability, the more the better. Agile requires you to let go of those a little, which Corporate America isn't willing to do. So if you join a Scrum shop, you will likely see cod-Agile that goes through the motions of Scrum while forgoing the principles of Agile -- under pressure from the top.

<comment><USER26> Is this the case for every company doing scrum? I find some benefits in scrum:

1\. Having regular scheduled meetings reduces distractions. For example, someone coming along to chat about something while you are in the zone.

2\. The important things get discussed with the right people in the room. Decreasing assumptions

I think people tend to forget that the critical thing to get right with agile or whatever methodology you are following is:

1\. It is #1 about conversations between people.

2\. The conversations between people help you explore the complexity.

3\. The conversations help you surface assumptions, get alignment on what needs to be done

4\. It is not about 'tracking', but rather encouraging effective communication to converge on the best path forward.

So question:

If you had to design a better agile process, what would that look like?

<comment><USER27> > Is this the case for every company doing scrum? I find some benefits in > scrum:

I find a lot of benefit in many agile methodologies _on paper_.

But where the rubber meets the road, the principal decision makers have a vested interest in _not_ holding up the principles of agile.

> It is not about 'tracking', but rather encouraging effective communication > to converge on the best path forward.

For any path forward, managers need to answer these questions:

* What needs to be done?

* How long will it take?

* Are we on track, behind or ahead of schedule? (This needs to be answered at least once a day.)

* What, exactly, are the pain points? (Again, once a day at least.)

These can be summarized in a Scrum standup, but what managers really want to see is a detailed analysis. Hence the need for:

* Detailed task breakdown of each story/ticket

* Detailed time estimates on each task

* Detailed daily-at-least time logging on each task

So yes, it absolutely is about tracking. Tracking is _the_ central component of any corporate software process. Tracking is what enables your manager to get a picture of what currently needs to be done and how far along the team is in getting it done. Inasmuch as agile processes can exist in this environment, they must be reshaped to accommodate the tracking requirements. Which means they won't be agile anymore.

Tracking also provides the benefit of an auditable paper trail, so that when government regulators come sniffing around they have a nice log of who did what when on the software.

In short, Agile has by and large failed. It does not adequately meet the needs of upper and middle management of a corporate shop, for whom time is money and there are strict accountability requirements.

</comment></comment></comment></comment></comment></comment><comment><USER28> I was once a Jr Dev for the BBC too (back in the days). It was exactly as you described. Extremely beneficial in terms of personal development due to the culture it offered.

</comment><comment><USER29> Slightly off topic, but does anyone know if they still use Perl? I think the BBC iPlayer used it.

<comment><USER28> I do remember they used Perl for backend, and there was a resident Perl-guru. I'm not sure with all the new Zend engine refactoring whether Perl still lives inside the BBC ...

<comment><USER10> The BBC is bigger than just the online devs. In news we still have a fair amount of perl, mainly in Nagios checks and other bits of monitoring, but pretty much any news package you see coming in from abroad, and many in the UK, passes through a system with critical perl elements (JFE and davina). PHP is more prevalent for more recent developments - Raven is PHp for example - anything you see edited for the party conferences is recorded and edited on Ravens, whenever you watch Asia Business Report every clip you see is played out of Raven, as are the graphics running on the screens in the studios. The lower third graphics on ABR are casparcg loading templates that are ttraditional perl cgi (mainly just to insert various variables). The news archiving system in bureaus has a perl front end, as does the web part of the video production system. Our offline captioning system (webcap) is perl, and the standard ubuntu build we use on c. 1200 machines has a lot of perl tweaks to configure and monitor.

These are critical systems, but we don't have the resources of online/fmt/digital/whatever, of all those systems only Raven gets any active development (about 2 man months a year), we just don't have the manpower or the time, so don't expect to find a job wanting perl though :)

<comment><USER29> Thanks for the explanation!

</comment></comment></comment></comment><comment><USER30> Kinda ironic that BBC Desing and Engineering team would publish their blog on Medium!

<comment><USER10> Yes, especially given there's a proper BBC blog system ([http://www.bbc.co.uk/blogs/internet](http://www.bbc.co.uk/blogs/internet)). I wonder if the poster had permission to post this, or if it's just a personal blog. Hopefully he won't get in too much trouble if the latter.

<comment><USER16> We're trying out Medium as a blogging platform because it was seeming like the BBC Internet Blog wasn't reaching our intended target audience any more. Better to go where your readers are than expect them to come to you.

</comment></comment></comment><comment><USER31> Sorry to stray offtopic, but are remote junior dev jobs feasible?

<comment><USER32> you need to be in the office as a junior dev because you don't know what you don't know and you can learn a lot through osmosis

<comment><USER33> Learning by osmosis is just not a thing. You can't just smack a junior in the middle of a team that doesn't effectively do remote, but a team with a good remote culture should certainly have no issues with a junior being remote as well.

<comment><USER32> how does a junior dev know the difference when accepting a job offer? (aka you don't know what you don't know)

</comment></comment></comment></comment><comment><USER34> Thanks for sharing.

In regards to the BBC however, and on behalf of my SO, I am curious how to get your foot in the door as a script writer (or as something related to this). Does anyone have any insights/tips/contacts that they would give to someone interested in becoming a script writer for the BBC?

<comment><USER35> [http://www.bbc.co.uk/writersroom/](http://www.bbc.co.uk/writersroom/)

<comment><USER34> I was hoping for something other than this. This is something that I am already aware of.

<comment><USER36> Write, pitch, repeat. Working as a runner might help you network and understand the industry, there are various mentorship schemes, but ultimately nobody gives a shit unless you've got a great script. You don't need permission from anyone to write a script and send it to a commissioner.

There's a mile-long queue of people who want to be a script writer, but a much more exclusive club of people who actually write and pitch scripts regularly. As the great Ronnie Coleman said, "everybody wants to be a body builder, but ain't nobody wanna lift no heavy-ass weight".

</comment></comment></comment></comment><comment><USER37> I hope they fill their diversity quota and don't just hire people from the huge white pool. because I want them to fail.

</comment><comment><USER38> Going from Jr to Sr in an organization is "easy/ier." Making the same progress as a freelancer/contractor is more difficult.

<comment><USER39> Most contractors are senior devs from my experience. One reason to go contracting is if you're a senior dev already and your career progression seems stuck because you're at the top of salaried positions in your company already. Going contracting is a way to get a pay rise for people like that.

<comment><USER40> Going contracting in IT in London is a way to get a pay rise for anyone. A senior dev contractor will likely make more than a director or architect at the same company. The whole situation is wacky.

<comment><USER39> Yeah that's true. But to get really high daily rates you need to be senior dev with decent amount of experience from my experience.

I agree the whole situation is a bit ridiculous. But when in majority of companies salaries for developers are limited to something like 60-70k.

This has been slowly changing and there are more companies willing to pay up to 90k but even then as contractor you can make equivalent of 120k or more even after still taking 25 days off per year.

</comment></comment></comment></comment><comment><USER41> Didn't the BBC outsource all of their programming jobs to Siemens? I had a few friends there who were TUPEd.

<comment><USER10> No, they tried doing that - first into an external company (BBC Technology), then in 2006ish they sold that off for something like £500m. Some programming jobs went (Coledia, which was attempts to commercialise things like BNCS and Jupiter), but the software jobs that were really close to the business like the news website stayed in house. Since then things like iplayer were built in house, and obviously R&D were never moved out.

Other technology that moved included areas like networks, most commodity IT (domain controllers, file servers etc), and for some reason the main area that looked after satellite bookings, routings etc (analog video distribution and audio tag frames are fairly core broadcast technology). However the news area that did this stayed in house, as did most of the desktop support in news (but not elsewhere), and most of the broadcast support. Except in Glasgow where pretty much everything was moved to Siemens.

It was a total mess, and it still is a bit of a mess. Many of the people who were outsourced are still working for ATOS (who took over Siemens/SBS/SIS), in fact I think they even kept the final salary pension which everyone else lost a few years later. A few who had been moved out were moved back in too.

However that all seems to be changing again - I believe most of the Atos jobs are moving from Bracknell to Eastern Europe as part of the new contract, and the WAN connectivity which Atos held (through vodafone) has recently moved to BT

<comment><USER41> _However that all seems to be changing again - I believe most of the Atos jobs are moving from Bracknell to Eastern Europe as part of the new contract_

Yes, it was reported in El Reg that the BBC claim they have to lay off all their UK tech people in order to afford to close the salary gap between their already incredibly well paid on-air performers. Funny how _commercial_ they can be when it suits them.

</comment></comment></comment><comment><USER42> Curious any companies in the Us can self-proclaim having similar environments? BBC only hires engineering in the UK

</comment><comment><USER43> By grooming them?</comment>


Gas Lines Are For Morons: A Homebrew Emergency Gasoline Recipe - <AUTHOR> http://vimeo.com/52755747 How to make a quick and dirty auto fuel/gasoline substitute that'll run your car just fine with stuff you can buy readily at Home Depot. <comment><USER2> 10 bucks to the next guy who videos himself trying it</comment>


Hit Reply – Episode 0: Yet Another Startup Podcast? [audio] - <AUTHOR> https://hitreply.co/ep/0/yet-another-startup-podcast/ <comment><USER2> Related: if anyone hasn't listened to the first season of Gimlet's "Startup" yet, it's excellent. Former host of NPR's "Planet Money" records all the hard parts of starting his own podcast production company.

[https://gimletmedia.com/episode/1-how-not-to-pitch-a- billion...](https://gimletmedia.com/episode/1-how-not-to-pitch-a-billionaire/)

I liked season one more than season two because I felt that the Dating Ring founders were a little more guarded about their vulnerabilities and shortcomings, whereas Alex laid it all on the line. (YMMV on this opinion.)

<comment><USER3> Season one and two were great! Too bad the third season got swamped in commercials and irrelevant stories. Wish I could pay to avoid the insane amounts of commercials that makes many promising podcasts unlistenable!

<comment><USER4> Season three was my favorite of all the seasons!

I thought it was much more interesting to learn about non-tech small businesses.

</comment></comment></comment><comment><AUTHOR> Hey all,

Super excited (and only a tad nervous) to announce our new podcast, Hit Reply

Hit Reply is a new show that gives you an inside view on what it's like to start a startup.

We will be sharing the lessons we've learnt going from 5 years of working on side projects, with ZERO launches as a result, to now having launched 9 separate side projects in the past 2 years.

Having now learnt how to launch (and written a book about it: [http://learningtolaunch.co/](http://learningtolaunch.co/)), we're now focussed on starting an actual, bootstrapped startup.

The podcast will be charting that journey.

Nice and short, with the episodes under 20 minutes.

We'd love to hear your thoughts, just _Hit Reply_ and let us know :)

p.s. We send a small weekly email with each episode every Tuesday, you can sign up on our site if interested: [https://hitreply.co/](https://hitreply.co/)

<comment><USER5> Under 20 minutes is awesome. Sometimes podcasts are way too long. 20 minutes forces you to just talk about the most important things.

<comment><AUTHOR> Agreed giarc! Our favourite podcasts are short and to the point, we think this works best for everyone :)

</comment></comment></comment><comment><USER6> Please, can podcast creators set up an RSS feed when they release their initial episode? And not the RSS feed through Soundcloud, that's just enough effort to get to and copy into my podcatcher that I'm not going to do it. I subscribe to tons of podcasts and will give anything a shot if I can subscribe in the few seconds it takes to do it directly through a podcatcher.

<comment><AUTHOR> Hey you're right Raoul. We missed a trick here, but honestly didn't expect to be up here on the homepage here just yet!

Next biggest priority is to sort this out. In the meantime, here's our Soundcloud RSS.

[http://feeds.soundcloud.com/users/soundcloud:users:245437295...](http://feeds.soundcloud.com/users/soundcloud:users:245437295/sounds.rss)

<comment><AUTHOR> So I just hacked in a super obvious link to the RSS feed on the page.

[https://hitreply.co/ep/0/yet-another-startup- podcast/](https://hitreply.co/ep/0/yet-another-startup-podcast/)

Hope that helps!

<comment><USER7> Might be useful to link this on the front page too. Also, I usually do a "<ctrl-f> rss" to try to find a link when it doesn't show up in Pocketcasts.

</comment></comment></comment></comment><comment><USER8> Would love to subscribe but it's not showing up in Pocket Casts... Where can I find the RSS feed?

<comment><USER9> I'm in the same boat -- happy to sub and give it a listen, but needs to be coming up in PocketCasts search. Not interested in changing my podcast workflow or signing up for emails at this point, sorry.

Maybe a lesson for a future episode about having all the ducks in a row before the marketing push :)

<comment><USER8> You can actually load in a RSS feed into Pocket Cast by searching for the RSS URL (that's why I asked for it). I submitted it to be indexed in Pocket Cast, so it should appear within 24h.

</comment></comment></comment><comment><USER10> I listen through PocketCasts, you really need to get this to show there.

<comment><USER10> For your info, I have like 60-70 podcasts there, imagine if I have them all bookmarked somewhere and I go to different bookmark to check whether there are new episodes... Not happening :)</comment></comment>


The Thousand Brains Model of Intelligence - <AUTHOR> https://medium.com/@Numenta/the-thousand-brains-model-of-intelligence-f1a70a6adf9c <comment><USER2> HTM has been covered here a dozen different ways.

Still waiting for good examples of how the technology solves problems better than other methods.

<comment><USER3> If they had a solution that was better than what was out there, and they are publishing their research, then it follows we should be able to find their novelty in their publications, right? So, I took a look at their publication track record on this topic [0], and there are a few red flags that stood out to me.

First, they're publishing at a pretty astounding rate, with new submissions roughly every 1-3 months for the past 3 years, with the same authors. I'm skeptical that a small (<5?) research team would be able to produce novel contributions at such a rate, which leads me to believe they're probably remixing previous works into incremental publications.

Second, all of their publications are in neuroscience journals, which may not be up to date with the latest research going on with HTM in (for example) computer science. NIPS does have a computational neuroscience track, after all - I would have expected at least some interdisciplinary leakage if the novelty was very high.

Finally, the journals that they're publishing in are relatively low-ranking, which also seems to indicate that what they're doing is not necessary very novel (as you said, perhaps just a re-hash of existing HTM research).

Also, this article was co-written with a marketing exec, so I think it's fair to bring a certain level of skepticism.

[0]: [https://numenta.com/resources/papers/](https://numenta.com/resources/papers/)

<comment><USER4> Unless I misinterpret what you are saying, your arguments only explain why you don't _expect_ to see novelty, but you haven't actually looked at the publications and concluded that they don't contain any.

</comment></comment></comment><comment><USER5> Hmmm - I've always thought you could see the effect of the vertical stack every time you were out for a walk and found yourself four feet in the air with your brain going "My bad dude - stick, not a snake "\- I only read the linked article, but on the surface, it seems like imputing magical properties to the stack it doesn't need - if you just look at it as a mechanism for allowing certain signals to move across the hierarchy because they are extremely beneficial in bundling the wider range of information that's rising up from the broader lower hierarchical layers. My 2c admittedly.

</comment><comment><USER6> > "...our brain is not building one model of the world. It's building > thousands of models in parallel!"

Isn't this discussed in Minsky's "Society of Mind"?

</comment><comment><USER7> This kinda sounds like each cortical column is doing SLAM in it's individual sensor modality.

<comment><USER8> as someone not familiar with the SLAM acronym, had to look it up [https://en.wikipedia.org/wiki/Simultaneous_localization_and_...](https://en.wikipedia.org/wiki/Simultaneous_localization_and_mapping)

</comment></comment><comment><USER9> Turtles all the way down then?</comment>


OpenJDK 11, Tools of the Trade - <AUTHOR> https://www.javaadvent.com/2019/12/openjdk-11-tools-trade.html <comment><USER2> I especially like to use jstack (well not like) but it really helps to figure out the issues when a process seems to be hanging. And you can even use it as a brute profiler, doing manual sampling and correlation.</comment>


AI is nearly as good as humans in detecting breast cancer - <AUTHOR> https://www.engadget.com/2016/06/19/ai-breast-cancer-diagnosis/ <comment><USER2> So are pidgeons: [http://www.bbc.com/news/science- environment-34878151](http://www.bbc.com/news/science-environment-34878151)</comment>


Google & Stanford create a digital brain that learns to identify a human face - <AUTHOR> http://www.extremetech.com/extreme/131717-google-and-stanford-create-a-digital-brain-that-like-an-infant-learns-to-identify-a-human-face-from-scratch

<comment><USER3> I think about this stuff a lot as part of my day job. I'll discuss the good and the bad. I would say the most important part of this paper is the 1. the Size and 2. the Number of images. The size of the model isn't huge.

Most people don't realize that computer vision research is done using tiny sets of tiny images. Think hundreds to thousands of images that are 32x32 grayscale or black and white. Google did 10 million 200x200 color images.

For a conservative comparison human vision can be thought of as two 15 megapixel cameras capturing at 30 frames per second. (The real numbers are higher and much more complicated.)

I suspect that given this amount and quality of input data most machine learning algorithms would have produced better than state of the art results.

Now the bad. Their model totally ignored time.

Most computer vision researchers work with static images. In biology there is no such thing as a static image. Everything moves. You move, your eyes move, the environment moves. The brain, as an exception, can understand static images, but the rule is motion.

A majority of features in biological vision are tied to motion. Light/dark change cells, moving edge change cells. A _huge_ portion of the information you derive from sight comes from the temporal context of a given moment. The change from moment A to moment B is directly encoded and learned and is often more important than the state at A or the state at B.

I'm not faulting them, in fact, I am extremely happy with their results, but I want to point out that these results can and will get _much_ better in the near future as the input size increases and people start to integrate temporal features into their models.

<comment><USER4> On the one hand I am an experienced software engineer with a computer science degree. On the other hand I was never interested in AI and I basically know "nothing" about AI, computer vision and artificial neural networks. AI always seemed too far off and bothered my engineering spidey sense for intractable problems.

So I may embarrass myself with the following...

The more software engineering experience I get the more neural networks bother me. I have not studied them in detail... and yet, they seem like a crappy solution.

Throw a lot resources at something, add a bit of math and push a pile of data through.

Does that ever lead to result that can't be bested though simpler more traditional methods?

For example, the math behind how the network is organized and learns, that same math can be used to write algorithms which reveal patterns in data. Patterns which can then be studied further.

Then there is the doing of things. What ever pattern is responsible for doing something in a network, the same function can be described much more simply by an algorithm.

It just seems like neural networks would be interesting only if an alien spaceship with stupefying computing resources fell on us. And it fell on us in such a way that we could fully utilize the power of this new super computer while at the same time we could not learn anything new about algorithms or anything else. Only then does it seem like "train the neural network" is a smart strategy.

In every other scenario is just seems like a decent if somewhat lazy start to an investigation. Really just a way to kick the tires of a problem.

So did I just completely embarrass myself with my lack understanding of ANNs?

<comment><USER5> If you try to design an algorithm, what you get is a model of how _you think_ your system behaves. If you train a neural network, what you get is a model of how your system _actually behaves_. In other words, a neural network does not embed any assumptions or preconceived notions of how the system ought to work. Intuitively, not incorporating knowledge of how the worlds works ought to be a disadvantage, but in practice it turns out to be not just an advantage, but an embarrassingly large one.

Neural Networks aren't the only common approach in modern AI research, but the other techniques (e.g. Support Vector Machines) have similar properties: they're dumb methods of finding correlations in data. The field of AI is slowly coming to grips with the fact that more training data trumps better algorithms.

That said, I sympathize with your frustrations. You can solve a lot of problems by throwing more cycles at it, but you don't _learn_ anything, either about the algorithms or about your target domain. For example, a human plays the game of Go differently than a machine. A human has an intuition of what moves are good and what are bad, and only considers a handful; a machine relies less on evaluating board position and more on brute-forcing through possible board configurations. As machines get more powerful, eventually the machines catch up to humans in ability, with that same approach. While their methods will become impressive in their efficacy, we learn nothing about how humans are so much better at evaluating board position and selecting moves to speculate on.

<comment><USER6>
      What are you doing?
      I am training a randomly wired neural net to play Tic-Tac-Toe.
      Why is the net wired randomly?
      I do not want it to have any preconceptions of how to play.
      Minsky then shut his eyes.
      Why do you close your eyes?
      Sussman asked his teacher.
      So that the room will be empty.
      At that moment, Sussman was enlightened.

\-- Jargon File

</comment></comment></comment></comment><comment><USER7> The system apparently did not require _any_ training by humans; instead, it learned to catalog different types of images, including those of human faces, _on its own_. (In other words, all images were unlabeled.)

Paper here: <http://arxiv.org/abs/1112.6209v3>

[UPDATE: fixed erroneous statement.]

<comment><USER8> With all the random hyphens in the text, I can't help but read it in the voice of G-Man from Half Life. Creepy.

</comment></comment><comment><USER9> The original work was posted and discussed here previously:

<http://news.ycombinator.com/item?id=4145558>

<comment><USER10> And the title is absurd.

</comment></comment><comment><USER11> This article is incorrect.

>Historically, machine learning has generally been supervised by humans. There are plenty of examples of computers identifying human faces (or cats) with incredible accuracy and speed — but only if human operators first tell the computer what to look for. That the Google/Stanford system starts from scratch and develops its own ability to classify objects is amazing.

Unsupervised machine learning has been around long before this feat -- which is nonetheless very impressive.

<comment><USER12> The algorithm they used did not exist before 2005. Also since 2005 this algorithm had been mostly trained using just 1 computer at time (usually with gpu's). The supercomputer setup is novel for this.

Most of the machine learning community had been disregarding this algorithm since 2005, until the past couple of years it started making dramatic showings, such as

\- Microsoft Research speech recognition system in 2011 (done by one of geoff hinton's students interning there)

\- NEC labs, ronan collobert - real-time natural languaege parser - <USER2> real-time parse ever - 2010 (trained on one computer for 3 months using wikipedia)

\- Google Research 16,000 node billion connection network - december 2011

<comment><USER11> Again, I don't mean to disparage the achievement! But the article implied that Google invented unsupervised learning, which they didn't.

</comment></comment></comment><comment><USER13> The article doesn't go in depth in the way of technical details (instead going for Terminator-joke knee jerkers), but I wonder how different this is when compared to a traditional neural net.

Sure, a neural network wired up to pixels of images wouldn't be able to come up with the word "face", but it would certainly group things correctly, right? Using keypoint matching to "grade" guesses, you could seemingly train the network appropriately.

Fascinating stuff. I just wish for a less fluffy article. Excited for the white paper.

</comment><comment><USER14> What are the current limitations of 'just' creating this on a much (much) larger scale? For instance, 160.000 or 1.6 million cores and would it be a significant improvement? And for which other fields would that work? I do know about neural net theory and I worked with them in college assignments quite a bit 20 years ago, but I'm wondering if anyone here knows what differences this kind of scale will make or if it's just interesting for still images (in which i'm very much not interested).

<comment><USER12> The amazing thing about this algorithm is that it works for any data type (my other comment talks about speech and nlp).

With more computers and more data it will keep getting better - i've thought a lot about this and following this stuff for a couple of years - so it's not just some idle speculation. (I broke this recent story on hacker news a few days ago, and from here it got picked up by the new york times and spread everywhere else).

</comment></comment><comment><USER15> is this covered in the Coursera.org course? :P

<comment><USER16> Indirectly, yes. The Coursera course teaches K-means clustering as an example of an unsupervised learning algorithm, along with a technique to work with larger data sets in a more manageable way (e.g. PCA to reduce dimensionality).

With the basic building blocks from the ML course you have a much better understanding of what Google and Stanford did. Andrew Ng is also the course instructor for the Coursera ML course[1].

I am presuming that supplemental readings and Youtube videos by Prof. Ng (e.g. <http://www.youtube.com/watch?v=ZmNOAtZIgIk>) allows a sufficiently motivated individual to at least partially replicate the results in the OP.

[1] Andrew Ng is also a co-founder of Coursera.</comment></comment>


Show HN: Email Marketing with RedCappi - Redesigned with a focus on simplicity - <AUTHOR> http://www.redcappi.com/?hn

<comment><AUTHOR> Hey guys we just redesigned our email marketing website from scratch with a big focus on simplicity. Interested in knowing what you guys think. Some questions that may come are, what's the difference between RedCappi and the other guys? Well for one, RedCappi is not as expensive as the other guys and the process of creating an email campaign is a lot more straightforward as well.</comment>


54-line if condition in gcc's reload.c - <AUTHOR> https://github.com/mirrors/gcc/blob/7057506456ba18f080679b2fe55ec56ee90fd81c/gcc/reload.c#L1056-L1110 <comment><USER2> For the curious, reload was written by Richard Kenner, who, while a wonderful guy, was not generally familiar with modern compiler architecture (graph coloring register allocation goes back to 1982, reload was started in the late 80's).

It essentially took the place of spill placement/code/legalization. Over the years, it grew rematerialization, instruction combination, copy coalescing, stack slot sharing and all sorts of other interesting scope creep.

While i believe it has finally been replaced by LRA for some targets, there were many people who spent years of their life trying to replace reload with separate, smaller pieces of architecture. No one has yet completely succeeded.

It is essentially an interesting object lesson in what happens when you just incrementally improve architecture to achieve performance goals without a stop-loss point for requiring new design.

<comment><USER3> As someone moderately curious, I hope I'm not the only one when I say: I didn't understand a word after "the late 80's". And that's only because I searched for "graph coloring register allocation" first.

<comment><USER4> For simplicity, a compiler manipulates an internal representation in terms of virtual registers. A register allocator assigns physical registers to these virtual ones, under the principle that different virtual registers may be assigned to the same physical one if they are not live (I.e. hold a value that will be used in the future) at the same time.

Spill code generation is necessary because at a program point, there may not be enough physical registers for all the live values, and code must be generated to spill some of them to the stack and reload them when needed. Legalization performs code transformations to eliminate target independent operations in the IR that can't be represented on the target. Copy coalescing eliminates the need for copies between virtual registers by assigning both to the same physical register. Rematerialization takes advantage of values that can be recomputed cheaply, and instead of holding them in a register for a long time, recomputes them where needed.

What makes this all so complex is that 1) most of these don't have polynomial time algorithms that produce optimal solutions: 2) the individual problems are mostly coupled. E.g. spill code itself uses registers, and so the interference graph (which summaries whether virtual registers are simultaneously live) might need to be recomputed or modified.

If you're interested in this sort of thing, Kieth Cooper at Rice has posted the lecture notes for his graduate compilers class online: [http://www.cs.rice.edu/~keith/512/Lectures](http://www.cs.rice.edu/~keith/512/Lectures). Register allocation is lectures 26-7.

<comment><USER5> Thanks everyone for watching another exciting episode of "Two Lawyers Explain Compiler Theory". :)

<comment><USER2> To be fair, I still manage the compiler team as well :)

</comment></comment></comment></comment></comment><comment><USER6> Please note that:

1) The goals of Reload are _very_ complex.

[http://gcc.gnu.org/wiki/reload](http://gcc.gnu.org/wiki/reload)

"Reload does everything, and probably no one exactly knows how much that is. But to give you some idea:

Spill code generation

Instruction/register constraint validation

Constant pool building

Turning non-strict RTL (Register Transfer Language, a very low level intermediate representation used in the backends of GCC) into strict RTL (doing more of the above in evil ways).

Register elimination--changing frame pointer references to stack pointer references

Reload inheritance--essentially a builtin CSE (Common Subexpression Elimination) pass on spill code"

Reload achieved them for the last 25 years(!)

2) There are more modern approaches to reach such goals, but knowing 1) it is _a lot_ of work before the goals can be achieved by some alternative code for all platforms (I don't know how far the developers got at the moment)

3) "Local Register Allocator Project" presentation by Vladimir Makarov, working for RedHat:

[http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=ge...](http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=Local_Register_Allocator_Project_Detail.pdf)

</comment><comment><USER7> Trivia: This code is older than many of the readers.

[https://github.com/mirrors/gcc/blame/7057506456ba18f080679b2...](https://github.com/mirrors/gcc/blame/7057506456ba18f080679b2fe55ec56ee90fd81c/gcc/reload.c#L1056-L1110)

<comment><USER8> I'm impressed that the blame log has survived intact. What SCM was originally used?

<comment><USER9> Probably Git? You know that's been around much longer than Github has, right.

<comment><USER8> Of course, but even without checking Wikipedia, I remember a time not too terribly long ago when git, and even svn, didn't exist.

<comment><USER10> And are pretty sure that GCC was around at that point!

</comment></comment></comment></comment></comment><comment><USER11> I was going to take a crack at breaking this apart into component functions, but I realized that I don't know where to draw the lines, or what to name the functions, without understanding the internals of this part (and probably other parts) of the compiler.

And that's why this will be here forever.

<comment><USER12> Actually reload has been replaced by LRA for x86/x86_64 in GCC 4.8 and work is ongoing to bring LRA to other targets. So it shouldn't be forever.

</comment></comment><comment><USER13> There's an off-by-one error in this thread's title. ;)

</comment><comment><USER14> Why put logical operator at the start and not the end of each line?

I.e., this style (used in this case)

          && (CONSTANT_P (SUBREG_REG (in))
    	  || GET_CODE (SUBREG_REG (in)) == PLUS
    	  || strict_low
    	  || (((REG_P (SUBREG_REG (in))

versus this style:

          (CONSTANT_P (SUBREG_REG (in)) ||
    	  GET_CODE (SUBREG_REG (in)) == PLUS ||
    	  strict_low ||
    	  (((REG_P (SUBREG_REG (in)) &&

I don't have a personal preference here, just looking for any practical pros and cons I may not be aware of.

More on topic, I don't see why keep such a big conditional and not move it out to its own function(s) (but this has been asked already in this thread).

<comment><USER15> I used to use the latter, in both code and maths, but I have switched to the former. My main reason is that having the operators (logical and otherwise) at the start of the line means they're more likely to be in the same horizontal position, so it's easier to see which lines are continuations of the previous ones.

<comment><USER16> It is also easier to comment out lines of code if you need to test something. This is especially useful in SQL, where you can quickly -- a condition or a column, without editing commas etc on other lines, eg

SELECT

        some_col

        , another_col

        --, and_another

        , and_more

FROM

        blah

EDIT: too bad formatting is screwed up :/

<comment><USER17> Isn't this behaviour exactly the same as with commas at the end? Here, to comment out the first line you would need to edit the second. With commas at the end, to comment out the last line you would need to edit the second last. Other than that, no editing of other lines is required.

In fact, in a language like Javascript where extra trailing commas are allowed, it seems that this argument makes even more sense for commas at the end than it does for commas at the beginning. Then, there would never be a situation where you would have to edit a line besides the one you were commenting out.

<comment><USER18> Trailing comma in SQL is a syntax error. It's also not allowed in JSON. And editing second last line can be a pain if you're testing something and are commenting/uncommenting the last line repeatedly.

</comment></comment></comment></comment></comment><comment><USER19> I'm more concerned with the fact that the function is more than 700 lines long.

<comment><USER20> 1996 lines to be precise.

But, to be fair it is well commented.

</comment></comment><comment><USER21> To be fair, the length is not _strictly_ 54 lines, since blocks of it depend on evaluation of the preprocessor (the #ifdef stuff). Still, that's pretty long. :)

<comment><USER22> That makes it even worse.

</comment></comment><comment><USER23> The rest of that file also has a ton of redundancies and verboseness its in logic that could be simplified considerably; e.g. I see this pattern a lot (428 ~ 435):

        x && y || !x && z

In this absence of side-effects, this basically implements a 2-input multiplexer and is identical to

        x ? y : z

In the 54-line condition the first obvious thing I'd factor out is SUBREG_REG(in) and GET_MODE(SUBREG_REG(in)), and then work out what else is duplicated from there. Here's my attempt at making this a little more readable. It's only 2 lines less, but this gets rid of all the repeated uppercase:

[http://pastebin.com/9zpr7Cd5](http://pastebin.com/9zpr7Cd5)

<comment><USER24> The way it was for me was that I only "got" the hang of the ternary operator once I learned what a multiplexer is and how it's implemented. Before that, it was something I used now and then (certainly didn't have any trouble understanding it or anything like that), but I never thought about it as some way to channel data through based on a condition. I just always thought of it as some handy form of conditional evaluation. Things "clicked" a lot when I learned about how digital hardware and muxes works.

</comment></comment><comment><USER25> This reminds me of a comment in a particularly hairy section of code in the MWC 8086 compiler written by dgc (among other things, author of MicroEmacs). I don't have the exact wording but it was something to the effect of

 _I am frankly embarrassed by the number of bugs that have been tracked to this function._

This was in the day before register coloring.

Earlier, I had the chance to write a code generator for an implementation language targeting the 8085 (!) and even that was sufficiently hairy that the team that took it over complained about the difficulty of improving the code.

[Edit] Time sequence correction.

</comment><comment><USER26> Why not break it up into variables or functions so that the logic can be followed while reducing the likelihood that a bug creeps in? What is the excuse for horrible code like this?

<comment><USER27> It's been getting the job done for decades, in perhaps the most popular compiler of all time. I'm willing to trust the maintainers' judgement on this one.

If they'd spent all their time needlessly fixing what ain't broke, gcc would've gone the way of GNU/Hurd.

<comment><USER28> > It's been getting the job done for decades, in perhaps the most popular > compiler of all time. I'm willing to trust the maintainers' judgement on > this one.

I don't trust anyone - myself included - writing code 1/10th as convoluted, age-of-product be damned. Code is not wine, old doesn't mean good. Neither do the maintainers, methinks: Looking at blame shows some refactoring.

> If they'd spent all their time needlessly refactoring, gcc would've gone the > way of GNU/Hurd.

And the lack of needful refactoring may very well send it the way of COBOL - with everyone merely wishing it had gone the way of GNU/Hurd. I've seen clang and LLVM replace gcc in both of my vendor toolchains that used gcc - suggesting they've already wished and then done something about that wish.

(Either that or licensing, but code like this stomps on the scales a bit...)

<comment><USER29> Old code is better - it's got bug fixes.

<comment><USER28> > Old code is better - it's got bug fixes.

It's also got prototypes that made it into production, ball of mud designs that encourage usage bugs, and C++ thrown together by that short lived intern who took a few Java classes, wrote everything assuming there was a garbage collector around, and took great care to avoid class trees with less than 3 layers of inheritance lest he be shamed for lack of 1337ness... then topped it off with a few __try/__catch blocks to deal with that one rare crash that nobody could find a repro case for.

Re-implementing bug fixes is a toll... sometimes a very worthwhile one, though.

<comment> qu4z-2 To be fair, new code frequently has those attributes too.

</comment></comment></comment></comment></comment></comment><comment><USER30> I will never have the skills to maintain let alone write a compiler. However, in a situation like this, I would break up the condition into a set of sub- conditions, set intermediate booleans, and progressively build upon the condition tests so as to make the code more intelligible and maintainable. No need for additional functions.

(Amusing incongruity: "boolean" fails the spellchecker in an IT forum :o)

<comment><USER31> >booleans

C doesn't support native booleans, C99 does-ish. And you can hack it in with

        #typedef enum {false, true} bool;

C uses ints, all the way down, for everything, until you hit turtles.

</comment></comment><comment><USER32> Needs more goto's.

</comment><comment><USER33> At least it's not all the conditions in a single line :)

</comment><comment><USER34> At least it's a proof that GCC is smart enough to understand and compile this condition :)

</comment><comment><USER35> #ifdef should be shot

<comment><USER36> There is no other mechanism to choose between <windows.h> and <linux.h>

<comment><USER35> Plan 9 manages to build the whole OS and userland for multiple architectures without using ifdefs, even cross compiling across CPUs with different endianness

</comment></comment></comment><comment><USER22> No wonder llvm is getting popular (I realize that there are other reasons besides codebase quality).

<comment><USER37> Compilers are complex, and these conditionals had to be evaluated in some way. Sure the author could have split it up into multiple if statements, but would have that really helped?

<comment><USER22> Yes, yes it would have, there is literally no question about that. It also appears that some of the parts of the conditions are repeated, so those could have been refactored.

<comment><USER38> I'm sure a good optimizing compiler like GCC would optimize out repeated expressions in conditions ;) (perhaps not if they're declared volatile(?))

<comment><USER39> _Definitely_ not if they're declared volatile</comment></comment></comment></comment></comment>


Ask HN: Are there any replay tools for Java suitable for production? - <AUTHOR> We have a problem with the reproduction of bug reports where I work. Most of the times it's due to the report being badly written, so what we do then is to take the customers database and just develop the fix using that. I've been wondering if there are better ways to do this, besides improving the quality of the reports.<p>I found this article that describes replay tools that record an audit log which you can then use to reproduce exactly each case: https://dzone.com/articles/if-you-cant-reproduce-bug-you The closest example I could find for Java was Chronon, but it doesn't seem to work like what is described in the article. I just need a log of what are the inputs that lead to a bug, a recorder of the whole JVM seems excessive. <comment><USER2> Have you looked into error reporting solutions? These can automatically capture uncaught Java exceptions within an application and send a crash report with relevant metadata (stacktrace, user actions, request info, etc).

Disclaimer: I work for Bugsnag, who offer such a solution

</comment><comment><USER3> Try Oracle's Java Flight Recorder. Was/is commercial, but is becoming part of OpenJDK 11.</comment>


OOP: History, and challenges for the next fifty years (2013) - <AUTHOR> https://www.sciencedirect.com/science/article/pii/S0890540113000795 <comment><USER2> What is the natural mathematical abstraction to describe object oriented programming? I always feel object oriented languages are some sort of poor approximation to some sophisticated functional programming concepts (lenses, comonads, etc), or havent realised what they are actually describing. Theres things that in practice feel very similar and some ideas that look dual (some sort or co algebra?).

<comment><USER3> There is a recent paper called "Codata in action" [1] that I think gives a nice explanation of (part of) OOP in terms of codata types.

But that paper also finally clarified for me why OOP is so awkward and unnatural sometimes. Why should an entire program be composed only of codata types? One would think data types (which are traditionally seen more in functional languages than OOP languages) would be more natural for most problems.

The specific combination of late binding and equi-recursive codata types that is approximated by OOP only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not.

The other major problem I have with OOP is that it's not a straightforward manifestation of an underlying mathematical calculus, but rather a hodgepodge of (not universally agreed upon) programming ideas that are best applied on a more à la carte basis. These ideas should be used when appropriate rather than taken as an indivisible paradigm to be applied wholesale to every programming problem. That's why I prefer to think of OOP as a design pattern rather than a programming paradigm: useful in some situations, but not to be used for every situation.

[1] [https://www.microsoft.com/en- us/research/uploads/prod/2020/0...](https://www.microsoft.com/en- us/research/uploads/prod/2020/01/CoDataInAction.pdf)

<comment><USER4> > OOP only makes sense when you're solving a problem that is naturally > expressed in terms of those features, but in my mind the majority of > problems are not.

How do you reach the conclusion that "the majority of problems are not"? But more importantly, the right question is not about the majority of problems, but the most common tricky parts of software, or, more precisely reduce the effort where it is largest, and the majority of tasks does not comprise the majority of effort.

I am skeptical about _any_ programming paradigm making a big difference, largely because evidence suggests none so far does, or, at least, that there are diminishing returns, but even if some programming paradigm could make a difference, I doubt FP would be it, and not only because empirically FP so far hasn't. The reason is that FP "helps" when the task is easy to begin with, and once you start dealing with interaction, it "devolves" into classical imperative programming. If any style could help, it would be a style that specifically helps with the hard parts, not the easy parts. An example of a more radical approach would be synchronous programming, that at least aims to make interaction/concurrency easier.

<comment><USER5> I think the benefit of FP is long term. Refactoring and maintenance of systems somebody else, not with the company anymore, wrote. 2 months into a project you could be forgiven for thinking oop and fp are equivalent. You haven't yet gone through a major shift in understanding the requirements.

<comment><USER4> I have been using both FP and OOP (and I started with FP before OOP) for a quarter century already and have written extensively about the use of mathematical formalisms in software ([https://pron.github.io/](https://pron.github.io/)). But the question isn't about me, but about the industry as a whole. How many decades with no large benefits do we need before we say, this isn't helping, we should look elsewhere?

<comment><USER6> I am not sure that OOP "isn't helping". I am not exactly an OOP fanboy, but we have to admit that, both inside and outside the industry (I'm thinking open source and hobby projects), OOP has contributed something. The industry has a lot of inertia, but it did eventually moved from assembly to high-level procedural languages, and from high-level procedural languages to OO languages.

However to what extent the move to OOP rather than FP (or logic programming) for instance is accidental rather than rational is a question one may ask. Javascript has nothing special but is wildly used just because it benefited from its quasi-monopoly on web scripting.

I think the problem is _efficient, easy, correct: pick two_.

With "easy" meaning not only "easy to program with" but also "easy to learn" and "easy to hire people".

Programming paradigms are false dichotomies. One can do pseudo-OOP with a procedural language, imperative in FP, FP-style in OOP. Not to mention the existence of multi-paradigm languages. Paradigms are merely about which programming style a language make easier, what is supported "out of the box".

The problem is then for the user to pick the right main paradigm for the task at hand. This is where programming becomes a craft - just like a proof strategy in mathematics is not dictated by the formalism, but is chosen based on intuitions (that is, expertise).

If there is no silver bullet, then maybe, from a programming language perspective, one can have a language that let us chose different pairs in (efficient, easy, correct) at different times. It is well-known that dynamic scripting languages make prototyping easier, but may not be viable in terms of efficiency and correctness for a finished product (Gradual typing tries to reduce this gap, it seems). Automatic memory management (garbage collectors) and more recently, languages with built-in concurrency features (instead of direct manipulation of OS threads) makes it easier to make less incorrect programs at the expense of some efficiency.

If we admit there is no silver bullet, then can we however to build silver bullet factories?

<comment><USER4> I agree with most of what you've said, except that programming paradigm and languages have not helped with anything significantly beyond a certain point. They helped early on, FORTRAN was more productive than Assembly, FP/OOP helped after C etc., but we're seeing diminishing returns. And guess what: some predicted that this is _exactly_ what would happen, incidentally, the very same person who said there's no silver bullet.

I'm not saying it's not possible to help, just that in a world of diminishing returns, it means that finding stuff that helps is very, very hard, and I think we're at a point where we can say that FP and OOP are not "the answer" to getting us further than where we already are, and start looking for other things.

> If we admit there is no silver bullet, then can we however to build silver > bullet factories?

I would say that the answer is no, for a similar reason we can't build halting-problem-deciding factories. If we had silver-bullet factories, then unless picking the right bullet is very hard -- in which case we've solved nothing -- then we have a silver bullet. There are some fundamental reasons for that, and I tried to cover some of them here: [https://pron.github.io/posts/correctness-and- complexity](https://pron.github.io/posts/correctness-and-complexity)

The one unanswered question is how far are we from the best we can do?

<comment><USER5> Wouldn't you say that the next logical step is to go up an abstraction then? Assembly -> C -> OOP/FP -> ??? In that case, wouldn't it make more sense if that abstraction was build on top of something which you can mathematically reason about?

<comment><USER4> First, you can mathematically reason about a program written in any language; I do it all the time with TLA+ [1]. It is certainly not the case that FP is more amenable to mathematical reasoning than imperative code, although the kind of reasoning is different: FP mostly relies on equational reasoning while imperative mostly relies on assertional reasoning. Synchronous programming, for example, relies on temporal reasoning.

Second, mathematical reasoning has its limits, especially as we're dealing with intractable problems. It doesn't matter if you can somewhat more easily reason about a simple three-line program in one paradigm than in another if most important programs are six orders of magnitude bigger. Unfortunately, program correctness (aside from some very simple properties) does not compose tractably (i.e. even if reasoning about components A1...An is "easy", reasoning about the composition A1 ∘ ... ∘ An can be more difficult than any computable function of n. So I would not put ease of mathematical reasoning about simple cases as necessarily the main priority, let alone the only one.

[1]: [https://pron.github.io/tlaplus](https://pron.github.io/tlaplus)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Interesting paper, thanks. Simula was without a doubt far ahead of its time. Though classes as modules is essentially implemented in Java. Concerning Smalltalk and it's features we now have another very interesting paper by Ingalls: [https://dl.acm.org/doi/abs/10.1145/3386335](https://dl.acm.org/doi/abs/10.1145/3386335).

<comment><USER7> For those interested: I'm working on a Simula 67 implementation, the parser already works: [https://github.com/rochus- keller/Simula](https://github.com/rochus-keller/Simula).

</comment></comment><comment><USER8> Very interesting paper and quite a good read for anyone whose OOP understanding boils down to whatever Java/C#/C++ do.

</comment><comment><USER9> In terms of future ideas :

Objects for multicore : I just don't buy it. The problem is that application concerns are orthogonal to implementation concerns and the point of programming languages is to abstract the implementation concern away from the application programmer. The hardware engineers / os engineers should focus on providing transparent access to system resources. Application concerns just don't map onto resource consumption in my experience.

I found the articulation of mobility/cloud rather odd. I thought it was going to be about lambda (AWS) and cloud runner (GCP) and other cloud serverless offers (???) which encapsulate a collection of functionality and abstract the concerns of providing a callable interface and resources to run the functionality. Instead it outlined a scheme for failover and fault tolerance, which seems to rely on centralised naming and a global OS. I can't see that OO has much to do with serverless, and I can't see that it is really implicated in the failover story articulated here either. I would make similar comments about the section on reliability.

What is really strange is that the future of OO doesn't seem to be focused (according to this paper) on the concerns of maintainability, abstraction, readability and reuse that I think made it an attractive line for development in the past, and this is perhaps why it hasn't persisted as "the way and the only way" of software development into the current decade. I think that the community has dead-ended on these challenges and is now casting about for other stories to move forward on, which is basically the death-nell for this line of programming languages I think. I think this is probably because everyone knows that the four challenges I mention are extremely hard - even to define and more so to metricate, let alone solve - and those who take them on will be out published by folks working on virtually anything else. Also, sadly for comp sci, these are fuzzy, soft and human problems to do with people and organisations - and computer scientists scorn those who do not deal with bundles of cut and dried efficiency equations and derived bounds.

How to move forward - well I do have a plan. The way forward is to infiltrate all funding bodies and then strangle all the maths grants that are avoiding the rigor of pure math funding by pretending to be something to do with software development or AI. The freed up money can go to engineers solving problems that matter and the theory folks can go and justify their work to the funding programs that they should be justifying their work to. Until that happens I am afraid that I see no future for OO !

<comment><USER10> isnt the actor model [0] by hewitt more akin to the "oo" that alan kay was talking about?

im pretty sure its quite rigeriously defined in mathematical terms... am i perhaps missing something?

[0] [https://en.wikipedia.org/wiki/Actor_model_and_process_calcul...](https://en.wikipedia.org/wiki/Actor_model_and_process_calculi)

</comment></comment><comment><USER11> "There may not be any programming a thousand years from now, but I'm willing to wager that some form of Dahl's ideas will still be familiar to programmers in fifty years, when Simula celebrates its centenary."

I wonder if the former is at all possible, will programming transcend to some higher level of sophistication that obviates the need for code, or language for that matter?

Or is there a way for code to attain the level of pure math, something independent of any specific language?

<comment><USER12> In my opinion mainstream software will be abstracted away to the point where you are working on defining and refining requirements. And will likely look very different.

Interestingly I feel software construction might become more craft man like in some areas. And in others a little more workman like.

To be open I feel my vision is very far away, maybe 40-50 years

<comment><USER13> I think it will be twofold.

On the one hand, there will be developers who use the most high level languages available and will do what you said: manage requirements, complexity and ambiguity while being able to find workarounds for the cases where performance would not be enough (there will always be these cases).

On the other hand, there will be people who specialize in building the foundations for the former developers. They will write high performant algorithms and datastructures and optimize code for devices where resources are scarce.

<comment><USER14> Isn't this already true to some extent today?

<comment><USER13> Yeah, I think it's already starting to become visible but the specialization will probably become stronger and more explicit.

</comment></comment></comment></comment></comment><comment><USER15> I quite enjoyed the paper and the many insights into object-oriented programming and its history.

Perhaps ironically, the part that I'm left wondering about is that "inheritance can be explained using fixpoints of generators of higher-order functions". Now I'm curious to study what that means, how inheritance can be achieved by "explicit parameterisation" ¹.

Another point that made me think is this prediction:

> In 1000 years object-oriented programming will no longer exist as we know > it. This is either because our civilisation will have collapsed, or because > it has not; in the latter case humans will no longer be engaged in any > activity resembling programming, which will instead be something that > computers do for themselves.

I wonder if it's true that in the far future, programming will be done by computers. I suppose humans could be dictating in natural language, or moving and shaping programs in virtual reality, but I'd still consider that programming.

\---

¹ The paper cited is: A Denotational Semantics of Inheritance - [http://www.cs.utexas.edu/~wcook/papers/thesis/cook89.pdf](http://www.cs.utexas.edu/~wcook/papers/thesis/cook89.pdf)

<comment><USER16> I think predicting what things will be like in the next 200 years is near- impossible. Maybe even the next 100. For the next 1000, I think the unknown unknowns are so numerous that people alive then would look back and just laugh at 99.9% of predictions, like we do over most of what people predicted in the year 1020.

Humans might have merged so thoroughly with some form of technology that it won't make sense to talk about humanity as a concept. I think natural language/VR programming would be considered extremely primitive then; maybe that's something we'll see over the next 100/200 years, but I don't think the next 1000.

If humans still exist and remain as mostly independent biological entities (perhaps due to a deliberate decision to minimize merging for ethical/philosophical reasons, even if it may be feasible), I think AGIs will be doing the vast majority of all programming. Maybe there'll be a bit of near-instant "compilation" of human thoughts into a wide variety of applications, enabled by neural interfaces, but I think they'll mostly be toys or just things we make for our own entertainment/amusement. (This might even happen in this century or the early 2100s; who knows.) I think it'll be like toddlers fingerpainting compared to what the AGIs will be concocting and running.

Maybe at best we'll sometimes be like middle managers, giving an AGI network extremely high-level requirements and some visual/neural examples/diagrams which they'll work with and adjust to deliver something close to what our true intentions were. Or maybe it won't even make sense to think of them that way, and instead we'll just consider them like extra brain lobes we automatically offload difficult stuff to, with bandwidth equal to or greater than our current intra-brain bandwidth - even though they won't be physically inside of our brains in any way.

<comment><USER17> Or we might discover that AGIs are inherently conscious beings, and that "offloading" to them is tantamount to slavery. No one wanting to risk competing with a superior species, humanity will be stuck with dumb computers.

Or humans would work around creating new conscious beings by building AGI substrate on top of already living beings.

<comment><USER16> It remains unclear if high and/or general intelligence necessarily implies consciousness. If that turns out to be the case, you'd be right, but we don't know enough about these possibilities yet.

We will very possibly have conscious AGI, maybe even well before the first superintelligent AGI is developed, but it may always remain a subset. And who knows, maybe it'll be the opposite, and constructing something akin to general superintelligence (by some subjective definition) will somehow turn out to be much easier and will come much sooner than constructing the first conscious entity.

We might come up with different terms to make the division very clear. Maybe "abio people" or "digipeople" or something. They'll be a completely separate category (kind of like animals and non-animals), and "AGI=ABP" will probably be an important philosophical problem, someday.

My blind speculation is that they may be correlated in some ways, but are mostly orthogonal. That is, perhaps you could have things that are conscious but very unintelligent and ungeneralized (like some animals), as well as things that are extremely intelligent and generalized but as conscious as an inert chunk of rock in a canyon.

If true, in the latter case such a thing would essentially be non-conscious by nearly all definitions. Or instead of a rock, perhaps it would be bounded by a minimum level a bit beyond that, but only to the extent that stars or viruses could also be said to be conscious. By the definitions where they are conscious, it doesn't presently seem evident we should attribute moral value to such entities. (Maybe our thinking will eventually change on that, but I don't think it's extremely likely.)

If the minimum bound turns out to be closer to or above, say, an ant, then I think it could get very slippery and we would have to effectively assume all AGI-seeming entities are or may be conscious, and limit how we can interact with them with laws and rights. Better to give the benefit of the doubt that something is conscious than to unintentionally treat a conscious being as if they aren't conscious. Though we can't currently seem to get that straight for animals, so who knows how things might go for future conscious entities.

</comment></comment></comment></comment><comment><USER18> As a present day Lazarus/Free Pascal programmer... I found this dive into history interesting. I had an almost allergic reaction to the idea of not type checking everything at compile time, but I do see how in some cases it can help if that is postponed.

What was REALLY interesting to me was the idea of objects as processes, and passing messages instead of function calls. The machine I'm using to type this has an 8 cores, and I can see that thousands are on the way eventually. Hanging on to programming models that only execute serially will become very time prohibitive in the near term future.

The idea of immutable variables always struck me as oxymoronic... but if an object is always resolved by id or name each time it is used, it resolves some rather nasty deadlocks, while allowing failure to be recovered from.

It seems obvious to me that I'm going to have to give up the ability to know exactly how variables are stored, in order to gain this flexibility. It seems like it will be worth the trade off, as compute cost declines, and communication costs remain relatively constant.

There is much in this to ponder, thanks for sharing.

<comment><USER19> > The idea of immutable variables always struck me as oxymoronic

It is, they're called constants.

<comment><USER20> That's a bad choice of name from one or more old languages that misused established mathematical terminology (e.g. C misuses void, constant and variable). An immutable variable (or in maths, just "variable') has a value that is unknown at build time but is constant at runtime. A constant has a known value at build time.

What nearly every language calls a variable today, is probably better described as a "reference" or "assignable", but sadly that ship has sailed and we'll forever be inconsistent with the math terminology for that one. Immutable variable is therefore a useful synonym for "proper variable".

<comment><USER18> Bad choice or no, the language is appropriate... Constants should remain constant at runtime. Variables should be allowed to vary. I don't see why people think immutable strings is a good idea, for example. How do you ever build a text editor, if the strings can't be edited?

<comment><USER20> The language and notation is inconsistent with hundreds of years of use in maths and confusing for kids learning both maths and programming (at least it confused me).

Regarding your skeptism of immutable data structures, it's best to think of immutable data and data structures as copy-on-write instead of update-in- place. This is a technique that is currently very underused, for example most programming languages do not come with "persistent" copy-on-write collections.

Here is an example text editor built using immutable data structures in C++: [https://github.com/arximboldi/ewig](https://github.com/arximboldi/ewig)

Advantages are excellent support for concurrency (background save works while you edit) and trivial support for undo/redo.

<comment><USER18> I tried diving into the source code, and immediately ran into something new :: everywhere and starting googling....

Namespaces?!? - Looks like a solution in search of a problem. The whole point of object oriented programming was to prevent reaching inside of objects from the outside, thus making then implementation independent from use... Namespaces seem to break that. Like leaving the cover off a machine so that you can push on one of the relay contacts by hand.

C, C#, C++ feel to me like Greek all sorts of keywords that make no sense, and random !@#$%^&*():"<>?[] everywhere

Somewhere at the top of all that code, there has to at least be one actual pointer variable where you keep track of the last revision, isn't there?

</comment></comment></comment></comment></comment></comment><comment><USER21> Anybody ever seen a systemic interpretation of OO (or even modularization) ?

A way to simply cut through possible spaces and divide things grossly in order to prototype without painting yourself in a corner ? an also minimize the amount of change if the the modules have to be changed (impact analysis comes to mind).

<comment><USER22> I don't think any interpretation of OOP comes close to being a full solution to software architecture. That being said I'll just copy a previous comment that breaks down why I think 'OOP' get debated in a circle without any resolution:

"OOP" is really three different things that people conflate together.

1\. Making data structures as tiny databases with an interface that simplifies storing and retrieving data correctly (no transformations in the class itself to other data types hopefully to minimize dependencies!)

2\. The school taught java/old C++ debacle of inheritance. This is where things fall apart. Inheritance means not only dependencies but opaque dependencies. It almost always means pointer chasing and lots of allocations. It used to be necessary because it was the only way to get generic containers. The speed hit to use a chain of pointers was also much smaller. In modern times this destroys performance and is not needed due to templates.

3\. Message passing - 'at a certain scale, everything becomes a network problem'. I think the flexibility in having this integrated into the core of a language like smalltalk is not a good trade off, but I do think message passing at a courser architectural level offers large benefits without limiting the speed of more granular and fundamental data structures and functions.

I think OOP will always be debated in a circle because people conflate these three aspects. The first I think is extremely useful and vital. The second I think is obsolete. The third I think should be treated as a higher level architecture approach with large chunks of data passed around to large non- trivial modules/libraries/nodes/plugins etc. The higher level can be more dynamic and flexible because the overhead for a flexible structure is much smaller if it is done with large chunks of data and not integrated into a language and used for vectors / hash maps / one line math functions, etc.

<comment><USER21> Honestly the 3rd point is cute but message passing seems like level zero of networking approach for large scale systems. I wish to find more thorough models.

<comment><USER22> I'm not sure what you mean exactly. Once you have a system of software running over multiple computers on a network you will have to copy data to other computers and treat everything as not just an asynchronous node, but a somewhat unreliable node as well.

I think this is a given, but I don't think software architecture is very well solidified on how to scale large programs even within the same process.

<comment><USER21> I mean at the software level I never saw design taking into account flow of message across the whole 'network', capacity, errors, redundancy, measure / optimizations. At best the message passing was a decoupling analogy.

</comment></comment></comment></comment></comment><comment><USER23> > In 1000 years object-oriented programming will no longer exist as we know > it.

Hopefully more like 5 years or less. OOP is worthless for programming computers and needs to step aside.</comment>


"middleware" violates English grammar rules - <AUTHOR> https://github.com/rack/rack/issues/332

<comment><USER2> Fuck proper grammar rules...

Middleware for the WIN.</comment>