dwc

> Recalling a conversation with Boris

Good to know Boris is still there! Was Chuck still heading up the team when you left?

> a plan for a complete rewrite in C++

Oh, no! That's a real shame. I'd be all for a rewrite, especially considering their insane test coverage, but that decision worries me.

> That being said, as someone who has integrated CSPICE into several C++ and python projects, the modernization would be a very welcome change.

As someone who worked mostly with CSPICE in C but also with some other non-Fortran toolkits, I agree.

When I was working for LROC, most of the planetary geologists used IDL (Fortran-ish in many ways) but there was still plenty of actual FORTRAN floating around. Oh, look, in the last couple of years this legend of photometry worked up this new method and here's the associated Fortran code. That kind of thing.

I did actually rewrite both IDL and Fortran, but it was always smallish, single-purpose programs or functions.

Note that the SPICE Toolkit[1] is still written in Fortran today, translated to C using f2c, and the C version used as the base for other language support. The Fortran part is unlikely to ever go away, since support for processing past missions is crucially important and all that processing code was written in Fortran. Also, talk about your stable, backward compatible APIs...

1. https://naif.jpl.nasa.gov/naif/toolkit.html

> parts of gcc's architecture are created for political reasons to make it harder to decouple

This was a major, long standing gripe about GCC, and it materially affected its quality and usability. This was not an orthogonal matter: bad technical decisions were made in the interest of political goals.

> if equal time would have gone to gcc instead of clang it might be even better

I don't think so. GCC's position as the de facto choice for a free/open compiler, coupled with some of the political/organizational decisions of the project, made it easy for developers to say "it's good enough!" on such things. Viable competition is one of the few things that will shake a team out of that.

I think any company that would buy Delphi will agree more with me than with you.

If you're right and companies just can't see that or make it work, can the community do more with Lazarus? I have not played with that so I don't know how good it is.

> The pricing is just out of this wolrd. You get the impression that they try to squeeze every last penny out of their existing user base.

I used to think that about Delphi, various commercial Lisp implementations, etc. But after some time I've changed my view a little.

My change is because I realized that Delphi had its chance, and kept on trying as the chance slipped away. No amount of competitive pricing today is going to make a resurgence of Delphi happen. That door is closed, for all practical purposes.

The alternative is to offer products and support in a sustainable way and given the small number of people using Delphi professionally today, that means charging somewhat hefty amounts. IOW, their target market is business that has Delphi products that are worthwhile to maintain. In order to stay in business and provide service they have shed casual users.

> Not sure they saw a connection there...

In my experience, they try not to see the connection. If you try to show it, they'll listen for a bit and then rationalize. If you keep at it you'll begin to see irritation and even aggression.

That a fair number of CTOs have a decent technical background doesn't seem to help much, somehow. I've had this confirmed personally when I got together with a coworker from almost 20 ago who had moved into management. He struggled to keep experienced people because they moved for more money, because they were paying below market value. If I suggest something like paying more, he considers it and then some weeks later I find he's still struggling to figure out a way to keep people, having changed nothing of consequence.

It's my pet theory that (almost all) management wants programming/IT to be a commodity and are willing to pretend that it is, to their detriment. They demand that it be a commodity.

> abandoning systemd to build another... systemd

Well, systemd is a particular answer to a set of problems that have been well known for a while. Building an alternative solutions to those problems is not necessarily "another systemd".

> drama surrounding systemd

The quick summary: many people are critical of the architecture and design choices and implementation details in systemd in particular, rather than that the underlying issues it's supposed to address are real.

> but I've liked using [systemd] so far

This isn't surprising, as some of the problems it addresses are real, and a pain. But there are other implementations that also address many of the same issues. Whether those would make you as happy as systemd is another matter.

You're asking for a quick fix without knowing what the problem is. Lack of motivation is normally a sign of some other problem. If the problem is that you just don't like the work any more, maybe the only fix is not just a new job but a career change. If the problem is the project/manager/team then it might be possible to move to another team in the same company. If the problem is that you haven't taken any significant vacation in 5 years...

I would restate that as people not pushing through past their initial uncomfortable feelings and preferences. Similarly, of all the people who have ever tried Prolog only a small fraction got past the "this is weird" stage. Or Forth.

This unwillingness to learn something more than slightly different is limiting, and usually expresses itself in other ways as well. That does NOT mean that such people aren't good developers. You do run risks asking them to work outside their comfort zone, though.

People have different workflows, and different desires for what they want out of their editor. For myself, I have just enough vim config to turn off compat mode and enable a few things. I think the only plugin I use is fugitive for git. I used to be a full blown IDE person, but I found that I really don't need all that stuff. Vim as a more featureful vi makes me very happy and requires no ongoing maintenance.

> I think what people miss most often is that this is NOT a "one solution fits all" kind of thing.

Yes. There's a lot of hate for open offices, and I'm among the haters. But someone I have great respect for technically recently asked why, since they loved open office plans and that's what they currently used and it seemed perfect. Who's right? Both.

Also, there's a wide range within any given solution. My current job has an open plan, but my teammates and I moved to the other side of the floor and the difference is like night and day. Everyone around us are heads down techies, and it's more than quiet enough. Before we moved we were near people who spent significant time on phones or in video conferences. And they were event driven, resulting in them having not very busy times where they'd all just sit and chat. So same company, same floor, same job, but a very different experience. Luckily we had the option to choose a location and move ourselves with very little hassle. Not everyone has that option.

That's a great book. Be prepared in this while it is very gripping, it's not a terribly happy book!

Same here. Mostly I would just read man pages and write code, but every so often there's something that only works if you know the proper incantation (call ordering or whatever) and Beej almost always had the right answer, with sample code.

It's an orbit map (showing nadir of the orbiter).

I think a fruitful way of looking at what org mode gives you as... a way to pull together many organizational aspects of your life into one system, as opposed to having 5 different apps that have boundaries between them.

Doing an outline for that presentation next week, but need to put it down now, and don't want to forget about it? Schedule a reminder or due date right there in the document and it'll show up in your agenda. No switching over to a reminder app. Want to log time spent on it? Do it right there. In the middle of all that and get a phone call with a new task? You're a hotkey away from recording that info without leaving what you're working on.

For me it's the integration of all things organizational that makes it compelling.

Yes, LRO is still active. Also, you too can know where it is right now[1]!

1. http://lroc.sese.asu.edu/about/whereislro

There's a lot of truth in that. A few days ago I wrote a comment about rewriting a program from C++ to C and coming in at about 1/4th the code size. However, I didn't mention C or C++ in that comment because the real savings came from reevaluating requirements, lessons learned, refactoring, et al.

Some time back, someone here on HN posted a comment about rewriting a Java app in... Java. Same basic story of large savings, without changing language at all.

Studying the actual effects of language is hard (time/effort/budget beyond constraints), so people don't do it.

> Experienced programmers recognize what's happening and have the personality to stand up the project leader and get a simplified version of the requirements accepted.

Some years ago I was tasked with taking a program and fixing a major bug and adding a new feature. The original devs were gone, the code base was a mix of spaghetti code and a large number of design pattern layers. I brought up rewriting it but was told no, absolutely not. After thrashing around the code for a while longer I rewrote it anyway, taking the requirements from our actual usage in production plus the desired new feature, and was done in short order with about 1/4 the LOC of the original. A lot of supposed requirements fell on the floor, but none of them were being used and some of them never belonged in that particular program at all.

For someone like me, a "normal" programmer, this is the only way to achieve bursts of 10x productivity. At that same job there was another like-minded person I collaborated with. As a nuts and bolts dev I was as good or better than he was, but his ability to cut to the chase and somehow convince management was almost magical. 10x doesn't come from typing in code very quickly on sub-tasks.

> Having said that, I lament the issues that the OP brought up: poor naming, unfamiliarity with their language's data structures, etc. Those are issues that will come up. Especially naming.

Indeed. And those things came up in writing a fairly simple utility function, so they're going to come up later in some large codebase.

While you're seldom hiring programmers to write utility functions like this, this kind of test shows whether the candidates have a basic familiarity with topics that will definitely come into play in their day-to-day work. I regularly run into "professionals" who can't structure their code in sensible ways, who don't even try to name things well, don't think about edge cases, etc. As it turns out, you don't want these people gluing together library calls either, because you'll end up with a mess on your hands.

This wasn't stated as a test for Java programmers. Rather that most programmers chose to implement in Java because they were familiar with it.

And you have to ask, if they were familiar with Java then why didn't they choose one of the idiomatic approaches you suggested? I mean, the "list" part is not an internal requirement so you could easily build a tree/node structure on input...

"Please step over here, sir, while I contact my supervisor" is about what I'd expect at worst from a junior agent in this situation.

I think the real answer is that there should be some balance of manned vs. robotic missions. Where that balance lies is a matter for debate. Having worked on a robotic mission I am very much in favor of doing more of that.

As for me knowing about this... I have more perspective than most people, but it all comes from listening to scientists, who are the ones with knowledge of the science gains. I wish they had a bit more voice than they do.

Much of the problem in the things you mention is that those things are specific solutions that have been confused with goals. I.e., "we're supposed to build microservices" is a horrible idea, as opposed to "given this particular situation a microservice is a great fit".

Understanding the possible benefits and drawbacks of any solution is important. It's important in whether or not that solution is selected, but also to make sure that the implementation actually delivers those benefits.

It's very common in our industry to use "best practices" without understanding them, and therefore misapplying the solutions.

As someone who worked on a NASA Lunar mission (LROC), I can tell you that there are opinions both ways. With NASA on a shoestring budget, some scientists feel the best science return on investment is robots. But there are plans to put humans back on the moon that would not cost all that much more. If it weren't for the fixed budget, I'm sure almost all scientists would want manned missions.

Why? Go read some more about Harrison "Jack" Schmitt, who was on the Moon with Gene Cernan. Having a geologist on the moon enabled spotting things, making judgements, and then following up on the spot. Sending a scientist who can also pilot (and Schmitt was damned good) rather than only having military pilots changes the game as far as the science return.

Speaking of þ, it has a role is the oddball "Ye" in "Ye Olde ..." form.

https://en.wikipedia.org/wiki/Ye_olde#History

I once build an acceptance testing suite using literate programming. I had been handed a nice write-up by our resident physicist with all the maths for how things should work and I didn't want to lose that, so we cobbled something together that used latex math, had embedded test code, etc. These documents then served both as spec and as tests. IMO, this was a terrific use for literate programming. But we did not adopt literate programming as an overall approach, pretty much for the reasons you mention.

If your end goal is to produce some kind of largely static artifact then literate programming is fine. For everyday code where you iterate and refactor all the time, literate techniques have all the downsides of prolific comments.

It was also ][ on-screen.

> Assembly language is the lowest level of abstraction in computers - the point at which the code is still readable.

For simple enough instruction sets it was not unheard of that people memorized the actual opcodes. In school, at the transition from terminals to micros, a friend of mine walked up to one of the new Commodore 6502 machines and entered a simple program in hex directly into the monitor program. For a while I had the common opcodes for the RCA 1802 memorized, due to working with a project board without an assembler (writing assembly on paper, then hand assembling into opcodes, then keying in the opcodes).

There's no returning to those days and I wouldn't if I could, but I can't help but think that I was lucky to have experienced that for the knowledge and perspective.

I've recently started watching Curtis Stone. It's very interesting. I have no plans to start a small scale farm, but it's something I often think about. It would take finding some local niche that was very profitable.

In the meantime I'll just continue trying to grow more for personal consumption. Along those lines I've found OneYardRevolution[1] to be a nice channel.

1. https://www.youtube.com/user/OneYardRevolution

Dietary guidelines typically self-moderate to something that they think the populace has a chance of adopting. I.e., they don't want people to completely shrug it off as too drastic of a change.

I would like to see a different approach: show the actual best diet guidelines, and then explain which partial steps will do the most good. Or something like that. It's better to be up front with what's known and then proceed to harm reduction rather than telling people that these partial steps are where they should end up.