Hacker News Reader

dasmothon Refactoring Large Functions

Abstractions are great. But in my experience the kind of functions you get by pulling chunks out of a big (but working) function aren't often abstracting things that are terribly valuable. If you think the extracted function does make sense on its own, then of course go for it! But if in doubt, I'd prefer to wait until there's actually a second call site to make the motivation for the extracted function clearer (and stand a better chance of getting its interface right first time).

dasmothon Refactoring Large Functions

If I'm understanding you right, "C-like-syntax" languages generally allow this:

       function big() {
           let x,y,z;
           {
              // First bit
              let localToThisSection = 42;
              ...
           }
           {
              // Second bit
              ...
           }
       }

dasmothon Organizational Debt

There is. Try clicking the [-] beside a comment title.

dasmothon Refactoring Large Functions

Do people really prefer:

      function doFirstBit() {}
      function doSecondBit() {}

      function big() {
          let x,y,z;
          [x,y] = doFirstBit();
          [x,z] = doSecondBit(x, y);
      }

to:

      function big() {
          let x,y,z;
          // First bit...
          ...
          // Second bit...
          ...
      }

To me, it's no harder to find the portion of interest in the latter when making a local change, and substantially easier to understand the whole thing (because you can sit down, maybe with a printout if that's your thing, and read through it linearly without having to jump back and forth to the subfunctions). And passing data between the portions can quickly end up nastier than my contrived example above, at which point people start doing things like creating a class just to hold what used to be the function's stack-frame.

Not saying very long functions are something to celebrate. But if they're organised sensibly they're not a huge problem, and to be honest probably bother me less than functions which aren't abstracting anything terribly interesting and only get called once.

dasmothon Ask HN: 5 years from now; what do devs do?

Languages: Lots of Javascript (maybe more Typescript, but would be shocked if that had taken over completely). Probably quite a bit of Python, Ruby, Go, PHP. I'd be pretty shocked if something we haven't already heard of gains a big market share in five years. New languages are a slow-burn thing today. One plausible shift would be Rust edging out C/C++ in lower-level application/library development. But will be a slow transition, as a fraction of total code written, it'll still be quite small.

Stacks: I suspect we'll see more emphasis on making new-built software that can be sold to management as "cloud aware". Which in practice, probably translates to more Kubernetes. But again, mostly stuff we're seeing today.

Hardware: amd64 still dominant for servers and desktops. ARM for mobile, gradually making some inroads into the server space (but if it takes over completely, that's still >5 years off). Maybe some ARM desktops. Hopefully POWER will be hanging in there, and maybe some RISC-V hardware -- but only in niches. Number of cores will continue to increase, but addressable RAM and memory bandwidth will be even bigger limiting factors than they are today.

What are they developing?: Line-of-business CRUD apps.

Edit: Re-reading, this comes across as quite negative. I do think we'll see a whole lot of innovation in these areas -- just that it'll take multiple years to filter through to what the average developer is working on.

dasmothon The Waterfall methodology was a historic accident and they knew it

Yes, I think I'd agree with that. Good judgement can potentially help to avoid the unbounded time sinks. I've met a few people who's opinions I'd generally trust in that regard, but it seems to be a hard problem, and so far I'm unconvinced by any claimed heuristic solution (in particular, the approach of picking "active" libraries on the basis of lots of commits on Github seems more likely to get you churn, rather than support when you most need it).

I also think there are some break-points where adding libraries can change the nature of a project significantly. Think of old-school Javascript, loaded directly with a few script tags. In general "new style" JS (with many small libraries, a bundler, and probably some other tooling) brings some noticeable advantages (at least for larger applications), but you definitely lose something relative to the "no tooling, just hit reload" edit-test cycle.

dasmothon Ask HN: What was the first site to use “karma” voting?

Among the lineage of web comment sites I'm familiar with, I'm pretty certain it was Slashdot. They definitely had it in 1999. Might have been 1998.

It definitely wasn't Digg. According to Wikipedia, that wasn't even founded until 2004.

dasmothon The Waterfall methodology was a historic accident and they knew it

1. In house designed and built custom RTOS
2. In house designed and built custom hardware platform
3. Our entire UI framework was highly customized by us, for our specific needs

It turns out, when you control all the variables, making estimations becomes possible. It isn't easy, but it is possible!

That's an interesting set of observations there. I've been wondering for a while whether we -- as a field -- have been systematically underestimating the cost of using libraries. To my eye, the anecdata definitely seem to be on the side of projects going more smoothly when the dependencies are few and well understood.

Does anyone know of anyone doing research into this kind of thing?

dasmothon Write good git commit messages

If there's stuff that's valuable, I'd prefer to see it pasted into the commit message -- far less likely for links to get broken.

If it's long term valuable, i.e. "I considered obvious, attractive alternative algorithm X but it failed horribly because of Y", I'd prefer that to go in a comment in the code instead. Far more likely to still be noticed in three years time, after the code's been run through two different auto-formatters and otherwise mangled around.

dasmothon Write good git commit messages

It's drastically less helpful if anyone ever wants to look at the code separate from whatever issue-tracker you're currently using. Are you confident those IDs will be preserved (in a useful form) if you ever want to migrate away from Github?

dasmothon Write good git commit messages

This seems to have become really pervasive the last few years, and I recognise it’s sometimes driven by regulatory/certification requirements. But in the absence of those, what does this gain you over putting a sentence or three of human-readable motivation into the commit message?

dasmothon 'Dying All Tensed-Up': 30 Years Since the Troubled Secret Mission of STS-27

I'm pretty certain any such mission would have leaked by now. At least the fact of it, if not the details.

On-orbit servicing of friendly recon sats was considered pretty seriously, though: http://www.thespacereview.com/article/3390/1

dasmothon 'Dying All Tensed-Up': 30 Years Since the Troubled Secret Mission of STS-27

It was almost certainly a matter of policy (pre-STS-51L, there was still quite a strong push towards the shuttle taking over all US launches) rather than strict necessity. Some flights (STS-41D, for instance) launched civilian comsats which surely can't have had any terribly exotic requirements.

dasmothon ARM1 Gate-level Simulation

The actual simulation is at http://visual6502.org/sim/varm/armgl.html

dasmothon IBM z14 Microprocessor and System Control Design

When I first heard about eCLipz, I thought it was pushing towards a single processor architecture for all three series. From today's article, it seems as though z/Series machines still get quite distinct CPUs, though. Do you know to what extend these processors are relatives of the POWER9?

dasmothon Ask HN: Can you actually get a dev job without doing a stupid quiz?

However I've been to job interviews where they force me to code live in front of several people and I couldn't get half a line of code out before one of them will chip in with a "suggestion" breaking my train of thought. The code they want me to write is some algorithm that they have expected you to memorise.

This could actually be the test in itself. There seems to be a substantial contigent who believe that this is what a collaborative programming environment looks like, and they might actively want to select against people with a more shut-the-door-and-work-through-the-problem mindset. I'd argue that a pair programming exercise is probably better than whiteboarding-with-interruptions, but setting that up well is more work for the interviewer.

Edit: completely messed up the quoting in original!

dasmothon Ask HN: Can you actually get a dev job without doing a stupid quiz?

I get what you're saying, but seems a little harsh. And also makes me think of:

"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw.

dasmothon A remote UK community living off-grid

I think the requirement is "normally living in Scotland".

(I'm not 100% sure how this is enforced. It rather seems as though getting a cheap flat north of the border and declaring that as your normal residence for the duration of studies could be worthwhile if you can afford it...)

dasmothon A remote UK community living off-grid

This is why I'm excited about Starlink (and potentially other big LEO constellations as well -- but Starlink is the one I'm most optimistic about right now).

dasmothon A remote UK community living off-grid

Yes, I think it would be. I sincerely hope I live to see this become widely possible.

dasmothon Don’t work “remotely”

Was a reason ever given? I'm not exactly surprised by this, but it seems pretty irrational, especially if the distributed company is already working reasonably well (which presumably it is, if they've just closed another round).

dasmothon Why the world needs deep generalists, not specialists

My father started butchering lambs based on reading a book, and using tools already around the house (he might have bought a cleaver, but pretty sure that was after he'd done the first few). The first one took quite a while, but worked out fine. Did he ever get as efficient as someone who does it every day? Of course not. But it's very definitely a learnable skill.

I do agree that the invasion is a bit of an outlier, although even in that case there are questions of scale.

I've always loved that quote, but my reading is: on top of the everyday things, it's worth picking up several skills which require some deep study. No, you won't get them all, but having several -- and being open to learning something new if a good opportunity arises -- is valuable.

dasmothon Ask HN: What's the largest amount of bad code you have ever seen work?

What's the problem with "hand-rolled components"? Isn't that pretty much the essence of building non-trivial frontend stuff? Or does this have some special meaning in the Angular world?

dasmothon Should we bring back atmospheric testing of nuclear weapons?

Before sacrificing an island, you could always see if there’s somewhere that needs a harbour or the like.

This has been considered before, e.g. https://en.wikipedia.org/wiki/Project_Chariot

dasmothon Rocket Launch in New Zealand Brings Quick, Cheap Space Access

It’ll take some money, some talking (do you have a local university that builds satellites?), or, most likely, both, but there are ways and means of getting things into orbit.

See, for example:

https://www.cubesatshop.com/product/pumpkin-cubesat-kits/

dasmothon It Can Be Done (2003)

Thanks for commenting!

And yes, more than the pencil-and-paper aspect of this, what I find striking is that it's one person working quietly and alone, with a manager who was prepared to take "Still designing" as an answer. There seems to be very little room for that in a lot of modern workplaces, and I find that rather sad.

dasmothon It Can Be Done (2003)

Yes, I like it.

I'm not sure https://motherfuckingwebsite.com/ is the analogy I'd make though. It uses a non-trivial amount of CSS (about 5k) -- but not so much that it'll slow most people's downloads, and not a big "framework". It's got some somewhat distinctive branding -- you'll know instantly if you navigate away from the site -- but the elements don't take up too much of the screen. It actually has some responsive elements (try making your browser window narrow).

There's a few lines of JS to make the drop down menus work. But again, nothing huge.

It doesn't seem to be consciously avoiding anything. It looks to me like the work of someone who's started from a clean sheet and is trying to build a site that works for them rather than ticking off a list of best practices. And yes, I like the results.

dasmothon Ask HN: What are some interesting programming challenges to solve?

If you want enjoyable challenge in fairly bite-sized pieces, Advent Of Code [1] is hard to beat. And mostly pretty good for trying out functional approaches.

Personally, I’d argue that doing one or two more substantive projects might be more satisfying in the long run, though. Depending on your tastes, something along the lines of Niklaus Wirth’s “compiler construction” book might provide some inspiration.

[1] https://adventofcode.com/2018/events

dasmothon Ask HN: Companies using Racket?

This is a common argument, but I've not seen a great deal of evidence for it on the ground. Rather, there seem to be a decent number of LISP enthusiasts out there who end up working with more mundane languages in their day jobs. If you advertise a LISP position, and make it clear that it really is going to be mostly LISP rather than just a keyword to generate excitement, I can pretty-much guarantee that you'll get applicants.

In locations where developers are very thin on the ground (i.e. not Massachusetts...), things might be harder. There's always the possibility of hiring remote.

dasmothon Actors for Squeak Smalltalk

The original Smalltalk was pretty close. By Smalltalk-76, they'd switched to calling methods synchronously (although still naming the calls "messages", I believe).