srparish

Joined 17 years ago

Karma
111
Submissions
41
Member since
Apr 26
[ my public key: https://keybase.io/srparish; my proof: https://keybase.io/srparish/sigs/boCUMrKKx1Lq7oYjHJqYJpOwaJHxRFj8-JiZ1JGt-ms ]
View on Hacker News

Recent submissions

Comment · 3 months ago
An extensible LLM agent (such as https://pi.dev/ or maybe hermes) written in common lisp could be interesting. Conditions and restarts and general debugging and repair of the live system, fast startup, native execution speeds, ability to add or replace or modify core functionality on the fly, solid multi-threading support, dynamic introspection including documentation, CLOS and multiple dispatch, saved images.
Comment · 3 months ago
If you have it enabled, and you're in custody or at a border or similar, and have biometric auth enabled on your phone/computer, they can hold it up to your face or force you to put your finger on it to unlock it. Search warrant be damned.
Comment · 3 years ago
Any word on when some of project amber features will come out of preview? I get excited each JVM release for some of those features, but it seems like most of the releases the preview count just gets bumped, and a few more get added to the preview holding pattern.
Comment · 5 years ago
The book "How to Measure Anything" by Douglas W. Hubbard has a chapter on using Monte Carlo simulations to do project planning and gather estimates. It's successfully been used for project planning large complex projects like building nuclear power plants, or projects that NASA or the Navy or similar have done.

The approach is slightly different then the article above describes. Instead it has each engineer go through calibration exercises until they can fairly accurately produce 5th and 95th confidence interval estimates. Then each engineer provides 5th and 95th confidence interval estimates for each item that needs to be worked on. Those confidence intervals are kept separate. You can then run a Monte Carlo simulation where each piece of work is weighted randomly assigned to each engineer that provided estimates for that particular item, and randomly picks a number based off their provided confidence interval estimate on how long it ends up taking them to complete the item for this particular simulation.

I was on a small team that used the above technique. We were in a large company trying to launch a new product, and given manufacturing lead time, and seasonality of the market demand, it was very important that we could provide a good estimate to the business when we could have the software portion of the MVP completed. The business provided us with what they thought the MVP features were, we further added in engineering tasks that weren't business facing, but needed to be completed. We confidence interval estimated those, and then also confidence interval estimated our personal vacation days, sick days, as well as a bucket of "unidentified work". The 80th percentile Monte Carlo simulation put us out a little more then a year. Our actual delivery was off by only a week from the Monte Carlo tp80; I don't remember in which direction, but it wasn't consequential to the business.

Comment · 5 years ago
> it's hard to find a project from years ago which doesn't "just work" with `go run`

That's not been my experience. On a team I was on, even code from six months prior would sometimes be difficult to compile. They keep changing how GOPRIVATE works, or how modules work, or how vendoring works with modules.

Comment · 5 years ago
They had the limbo language in plan9, which has similar features and quirks. It seems most probable that the outcome of the 45 minute conversation wasn't "let's build a language from scratch", but rather "let's iterate on limbo".
Comment · 5 years ago
Verbosity of code is more of a go thing these days:

  hasThing := false
  for _, v := range stuff {
    if checkForThing(v) {
      hasThing = true
      break
    }
  }
  if !hasThing {
    return false
  }
Java:

  if !stuff.stream().anyMatch(v -> checkForThing(v)) {
    return false;
  }
In the 2020s, loops are the new "goto", too much boiler-plate and ways to subtly be incorrect, much safer to use higher-level collection methods.
Comment · 7 years ago
+ By declaring a field/variable []Thing vs []*Thing you get different for loop semantics. Way to easy to think your mutating the array item, but only mutating a local copy or vice versa. If you change the field/variable you need to audit all your code to make sure you haven't broken things.

+ gofmt feels way out of date. These days clang-format (c++), prettier (typescript), black (python), scalafmt (scala) take care of wrapping/unwrapping lines such as function definitions or function calls. They basically cover all formatting needs so you never have to manually format anything.

+ Scope of element in for-range loop isn't right, so capturing that scope in a lambda does the wrong thing with no warning.

+ Encourages use of indexes; which is error prone, most modern languages allow writing most code without needing indexes using map/filter/reduce or comprehensions.

+ No help from type-system for use of pointer without nil check.

+ Very easy to get nils in places one would hope to be able to prohibit them in. EG Using pointer as a poor man's unique_ptr<> means that I also get optional<> symantics (without the type checking) when I don't want or expect such. Also allows for aliasing when I don't want or expect such.

+ Difference between '=' and ':=' is silly, especially since ':=' can be used to reassign values. Even more frustrating that ':=' creates shadowing in nested scopes, so doesn't always do what one would expect it would do, such as accidentally creating a shadowed 'err' that doesn't get checked.

+ if/switch should be allowed to be expressions, allowing much safer single-expression initialization of variables, rather then requiring default initialization and mutation, which is much easier to get wrong.

Comment · 7 years ago
By productive you mean having developers repeatedly manually create loops that are the poor and verbose equivalents of map(), filter(), and reduce()? Out of go, scala, c++, java, python, typescript; go is the least productive language I've used in the last decade.
Comment · 7 years ago
My understanding is with EKS or similar you still have to manually size your kubernetes cluster, that is you have to make sure there's enough hardware instances in your kubernetes cluster for whatever scaling you'll need. With fargate you're effectively using AWS's own cluster. Your service can scale up and down, and you only pay for the resources that your service actually uses.
Comment · 7 years ago
Kotlin, java has been adding functional features
Comment · 9 years ago
Comment · 10 years ago
Comment · 10 years ago
Comment · 10 years ago
Are future versions of cats going to require the typelevel scala?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton