srparish

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.

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.

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.

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.

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

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

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.

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

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.

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.

Kotlin, java has been adding functional features

- Software Engineering Daily: https://softwareengineeringdaily.com/category/podcast/

- Changelog: https://changelog.com/podcast

- Functional Geekery: https://www.functionalgeekery.com/

- CppCast: http://cppcast.com/

Language wise scala.js[1] with cats[2] or scalaz[3]. The FRP story there is unfortunately more complicated.

1| https://www.scala-js.org/ 2| http://typelevel.org/cats/ 3| http://scalaz.github.io/scalaz/

Are future versions of cats going to require the typelevel scala?

I also don't have a lot of need for scientific computing; Julia has the potential to be a really compelling replacement for Python for general purpose scripting.

Not a book, but scipy had a two-part introduction to Julia talk that's worth watching:

part 1: https://www.youtube.com/watch?v=vWkgEddb4-A

part 2: https://www.youtube.com/watch?v=I3JH5Bg46yU

That's great to see. It's sometimes hard to keep up with everything that's going on. Incidentally I really got a kick out of the recent s/Uint/UInt/ rename (https://github.com/JuliaLang/julia/issues/8905). It took a day or so to propose and do it. To compare, java will probably never fix it's spelling oddities (for example int and Integer). Very refreshing to see fundamental things like that be fixed and so quickly!

* lack of threads: they do support multiple processes which can be useful for splitting up work for large computation, but not a substitute for threads

* module compilation is not cached, so if you use very many modules your start-up times can be slow

* error messages sometimes require some head scratching. For example, it's not uncommon to get an error that there's no available function convert(::SomeType, (Some, Args)) when there's no obvious convert() to be seen in the code in question. Occasionally the stack trace will be missing from errors, or there won't be a line number. Obviously this is improving quickly, but can be frustrating.

With the title I was expecting that people were finally fed up with getters/setters and all the other ceremonial bloat that's associated with java. Maybe tomorrow.

I'd recommend "C++ Primer". It's been updated for C++11, and is written in precise and clear language. As a C programmer, I find understanding details are important; Accelerated C++ was just too chatty, casual, and vague for my tastes.

"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Knuth

It's not uncommon for languages and libraries to assume that millis are the smallest resolution. Java is getting better, but is still pretty hit or miss. But if you're writing performance sensitive code you're definitely in micros and maybe in high nanos. There's a lot of those in a millisecond.

The name made me hope that it would let you communicate from python with akka actors. Apparently not.

I don't work at google, but my team is in the same boat because of this bug: http://bugs.python.org/issue10394

Moving to python3 wouldn't be too hard, except we have some really complicated cheetah templates, and cheetah apparently has no plans for supporting python3 any time soon.

Some language generate a lot more noise then others--the noise is not at all correlated to actual usage or popularity.

I've had exactly the opposite experience. I've owned 3 thinkpads, 4 macbook pros (between my wife and i), and an ibook. The thinkpads are tanks that take any beating i give them and keep running. The ibook was solid. The macbook pros have been complete crap--breaking dvd drives, failing harddrives, failing keyboards, cracked displays, failing trackpads. On the dvd drives, Apple has refused to admit the problem, and has repeated deleted forums with people discussing it. They've completely lost me as a customer.