Hacker News new | past | comments | ask | show | jobs | submit | davesims's comments login

We came to the same conclusion at Kubos, and moved from C to Rust for most of our flight segment/application code (embedded Linux on the satellite OBC).

https://www.kubos.com/


Awesome, do you think it’s a hard sell for old school government contractors? I am passionate to write embedded systems with Rust, but I worry it will be too hard of sale to d school contractors with stacks already written C, and C developers on staff.


I've had a good number of conversations actually with some NASA FSW coders, and in general they're open to these ideas. NASA has a project with architectural and structural goals pretty well-aligned with what we set out to do at Kubos: https://cfs.gsfc.nasa.gov/Features.html

The biggest challenge is to prove that it works. The space software community historically is very conservative and risk-averse, and mostly for good reason. As Kubos (and hopefully others) get more flight heritage with Rust on the flight segment, it'll be a much easier sell.

That's the biggest obstacle I think. Someone will have to break the seal and establish that "Rust in Space" actually succeeds consistently, then larger "trad space" organizations will follow.


As someone who was directly involved with hiring & managing Bryana let me set one aspect of this conversation to rest: Bryana's performance _across the board_ was top-notch, without qualification.

She commanded, and continues to command, respect from her peers for both her technical contributions on a very challenging tech stack, and product savvy in an extremely complex business domain. I was on her interview and there was no question of moving bars. It didn't even come up, because she was so very well-prepared. We just evaluated the performance and hired the best dev for the position, end of conversation.

On the job she spoke with authority and confidence in standups and earned every single bit of responsibility she ever got. Mention her to anyone who's worked with Bryana and you'll get the "eye roll of respect." She's so talented there was a minor running joke with a couple of us that we should keep a countdown clock of "minutes till I work for Bryana."

I only wish that early in my career I could have been half as well-rounded and with a fraction of the aptitude, product savvy and technical depth Bryana has.


Have you made any decisions about Bryana's responsibilities that were motivated by her gender, rather than her personal strengths?

Putting your only female dev in the position of representing your company at conferences suggests that she's taken on the role of "token female". If this is coincidental, and she just happens to be the best spoken developer with the least stagefright, then clearly there is no problem. However, if you deliberately chose her because she is female, then you are doing her no long-term favors, and are engaged in sexist business practices yourself.

new_corp_dev put it better than I could: "If the industry sees a glut of women speakers who are there only because they are women, then the industry will have no choice but to acknowledge their token status."


> Have you made any decisions about Bryana's responsibilities that were motivated by her gender, rather than her personal strengths?

Nope. Fortunately for me, while I was in a position to make those decisions about Bryana (I've since changed gigs), her own excellent performance was the only thing I had to think about.

Look, I'll let Bryana's own career speak for itself, which I have no doubt it will, but for myself I'd have confidence putting her in front of any audience on any topic she feels comfortable talking about.

One other thing, if you know anything about how conferences work, CFPs/speaking roles are something managed by the conferences, not companies. Questions of 'token' or otherwise are best posed to the individual organizers of the conference in question.


So what? What harm is there in showcasing female workers? There's nothing about being a 'token' that precludes competence.


There's nothing wrong with showcase female workers, as long as you aren't doing so BECAUSE they are female.

Since you are constantly accusing everyone here of the Straw Man fallacy, let me provide you an example of an actual Straw Man argument:

>So what? What harm is there in showcasing female workers? There's nothing about being a 'token' that precludes competence.


Um, we must have different ideas of what that phrase means. "A weak or imaginary opposition, set up to be easily refuted". I'd have had to set up something, for that to be the case. Instead of, just exploring the previous comment's setup.


Nobody is questioning her ability or qualifications, only your decision to offer her opportunities and incentives based on her gender which her post implies were not also available to equally qualified male members of her team.

If you want to put the conversation to rest, simply clarify that point.


> only your decision to offer her opportunities and incentives based on her gender which her post implies were not also available to equally qualified male members of her team.

Her post only implied her own personal, subjective and utterly understandable anxieties on that point. My response was at pains to put both her questions and anyone else's to rest. She earned everything she got, and the comprehensive respect she received from her peers was without qualification. Never mind gender, she coded way beyond her years of experience. The main thing with managing Bryana was to get out of her way and let her do outstanding work, which she did.

> If you want to put the conversation to rest, simply clarify that point.

Was there something ambiguous to you in my statements here?

* Bryana's performance _across the board_ was top-notch, _without qualification_.

* ...she..._earned_ every single bit of responsibility she ever got.

* We just evaluated the [interview] performance and hired the best dev for the position, _end of conversation_.


This is pretty unhelpful as this (your) submission wasn't discussed at all.


>> Note that the word "claims" shows up not even once.

That word actually shows up exactly once in each episode.

>> In the first episode, they insinuate that IV doesn't pay inventors like they claim. In the second episode, turns out that they do pay quite well, but oh look! that inventor is totally a schmuck for ripping off his coinventors! (Is he really the kind of inventor that IV is paying?!)

Yes, IV paid Chris Crawford -- the one example given by IV of an "inventor" who made money -- for a stake in a patent. That's what IV does. They buy patents or percentages of patents. TAL never claimed otherwise. Crawford retained a percentage of interest in ongoing revenue obtained in court, which was distributed accordingly.

As to whether Chris Crawford is a schmuck and ripped off others, or whether the invention in question was even his to sell or was his idea to begin with, I think this court transcript from a case that he lost, speaks for itself:

---

Attorney: So the first paragraph of this document reads, quote, "This proposal, it is in response to Jack Byrd's idea to provide automated offsite backup services for PC users." And aren't you in the second sentence saying that Jack Byrd had an idea to provide automated offsite backup services for PC users?

Chris Crawford: No. What I'm saying is that Jack Byrd had an idea of me pursuing the automated offsite backup services that I had--

Alex Blumberg: Chris Crawford then launches into a rather surprising explanation for how the sentencing that this business was, quote, "Jack Byrd's idea," doesn't actually mean that the business was Jack Byrd's idea. His explanation? He was using the apostrophe S incorrectly.

Chris Crawford: As far as the apostrophe S-- and I'm still not clear if you're trying to derive a specific meaning with respect to the apostrophe S--

Alex Blumberg: Of course, what would a sentence reading, "in response to Jack Byrds idea" even mean if the S was plural?

Attorney: I'm asking you, though-- you certainly know what the use of an apostrophe S means, do you not?

Chris Crawford: [SNIFFING] As I've written documents over the years, there are times when I use an apostrophe S, and it seems like I'm supposed to use an apostrophe S. But I have to say that my grammar is not strong enough to tell you right now with clarity when an apostrophe S is used.


Hmm, I'm been unable to respond because I get a "you're submitting too fast" error. Maybe I tripped some sort of flame detector. To avoid multiple replies, I'm consolidating responses into one mega-reply.

davesims:

> The word ['claims'] appears exactly once...

Yes, I worded my argument poorly. The word "claims" does occur, but it's not in the context of a patent's claims, but rather the claims made by a plaintiff. They discuss multiple patents in the episode, but not once do they talk about any patent's claims, and no discussion of a patent can begin without the claims. In fact, the journalists seem to make the very common mistake of interpreting a patent's scope based on what the abstract and other sections mention.

> TAL never claimed otherwise.

Oh, they very much insinuated it by emphasizing how difficult it was to verify instances of inventors getting paid.

Also, yes, the inventor was a schmuck, but that should have no bearing on IV or other trolls who claim to help inventors. The vast majority of inventors don't try to rip off their co-inventors. (Glass half-full: because most people are decent human beings. Cynically: incorrect inventorship, as in this case, can automatically invalidate a patent. If you search askpatents.com, you'll see this issue come up a few times.)

nickff:

> Bread refreshing method US 6080436 A

The main claim in that patent, as pointed out by belorn, requires a temperature of 2500 F to 4500 F. Toasters typically operate at temperatures at 310 F. I don't know what you get at 2500 - 4500 F, but it's not toast. The thing is, you don't even need to be a patent lawyer or an engineer to fact-check this little but.

> The engineers understand how patents work...

This, in my experience with multiple online forums and countless personal interactions over the course of 7 years, is rarely true. Pretty much nobody, especially the tech media making the most noise about patents, even knows what claims are.

I agree that patentese seems esoteric at first glance. But that is because it has this particular structure for legal and historic reasons. It's easy enough to learn, though. If you've had to debug C++ STL compile errors, patentese is a breeze. This was the intent behind my Blub/Haskell comparison: complaining about something wihout understanding it is really not contributing much to the discussion.

reitzensteinm: > Lodsys

In my eyes, Lodsys is clearly a bad actor. They are preying on solo developers who have no way to afford any kind of defense. Many trolls exploit the extreme cost asymmetries of mounting a legal defense, but by targeting such small players, Lodsys is taking it to new lows. In that sense I find IV to be more palatable because at least they pick on "someone their own size". (Lodsys has been linked to IV, but until some time ago, Lodsys had a page on their site explicitly disavowing any relation to IV. No idea why it's been taken down.)

Also, a general note about TFA: I don't see what's so landmark about this trial. Generally, trials are "landmark" if they break new ground, and while interesting because the defendant is formidable, this is a pretty run-of-the-mill lawsuit of IV vs another tech giant.


Thanks for the excellent, in-depth explanations.

I think that the TAL episodes were great at exposing the fact that there are patent trolls, and that there are problems with the current patent system. But your descriptions and analysis do point to some serious flaws with their reporting and explanations.

And yes, I remember first hearing the episode about the patent invalidation, in which everything hinged on someone's handwritten notes that happened to be written down. That didn't point to the fundamental issues here.

I think that a lot of engineers, especially HN readers (and including myself), are interested in the world of software patents, but lack the legalistic training to think through things the way you described.


re: bread patent. See here: http://www.google.com/patents/US6080436

The claims are that the heating element is set between 2500F and 4500F (claim 1b). The bread itself is held away from the element (sheets 2, 3), separated by air (which is not a great heat conductor), for between 3 and 90 seconds (claim 1c). Sheet 4 indicates that the 'cut fuzz & peaks' of the exposed face of the bread becomes toasted.

This patent describes a method of toasting bread using an electronically-controlled fast toaster.


Instead of hand-waving about the conductivity of air, what would have helped is a citation that clearly states how hot the heating element of toasters themselves get. (Really. Because I could not find a good cite either :-P)

The best I coud do was wiki answers: The heating element of toasters reaches 1100 - 1200 F [1].

If the answers.com link is not trustworthy, consider this: The most common alloy used for the heating elements in toasters is Nichrome [2]. Nichrome is used because it has a "high" melting point of 2550 F [3].

Not only does the temperature range required by this patent not make toast, it would melt the heating element in most toasters. The spec of the patent itself requires some kind of halogen lamp heaters.

It's pretty clearly not a "patent on toast". "Burnt to a crisp" toast, maybe, but not toast.

1. http://wiki.answers.com/Q/How_hot_does_a_toaster_get

2. http://www.toaster.org/works.html

3. http://en.wikipedia.org/wiki/Nichrome


I think it's a bit of a category mistake to call filesystem or database data 'global state' in this context. Virtually every application has external persistence of some kind and some way of referencing that persistence. Technically those references -- variables or classes that manage connection pools or IO utilities, etc. -- can be called 'global state', but that's generally not what the CS literature is talking about when it says 'avoid global state'. The Evil Global State of CS lore generally refers to globally accessible static or class-level values that refer to in-memory structs, objects or values of some kind, in the stack or heap, rather than external persistence. Filesystem and database access is usually taken for granted, and is ceded as the unavoidable level of 'global state':

http://c2.com/cgi/wiki?GlobalVariablesAreBad

State, in general, at any scope, can make things difficult no doubt. But global state is classically bad because it's hard to reason about across large chunks of distributed code, pollutes namespaces, creates concurrency nightmares, etc. Reducing the scope of state to a manageable range of, say, less than a dozen lines of code, into short-lived references, is clearly far better than the alternative and a reasonable approach in the vast majority of cases. Calling it 'poison' ratchets the rhetoric way beyond the gravity of the problem. No, local state is not considered harmful.

What it seems OP is really talking about in practical terms is pure stateless programming, where the application has no implicit or explicit references to a value whose authoritative data resolves in main memory. If you were to tell me the only state you have in your application is Filesystem or database data, "just beyond the edges of our program logic," I'd say you'd basically achieved the fabled 'stateless' programming ideal, long held as a kind of Holy Grail of functional application development, and as OP points out, that's not often achieved even in the strictest functional environments.

I don't want to diminish the points made, the article was instructive to me as yet another anecdote about the perils of shared mutable state at any scope. But the fundamental principle, that one should avoid shared mutable state as much as possible -- which is the upshot of the essay -- has been axiomatic for quite some time.


> If you were to tell me the only state you have in your application is ... "just beyond the edges of our program logic," ... that's not often achieved even in the strictest functional environments.

It's actually a pretty common design pattern in clojure to keep all application state in a single datastructure (eg http://www.chris-granger.com/2013/01/24/the-ide-as-data/ http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r... http://channel9.msdn.com/posts/Rich-Hickey-The-Database-as-a...).

> But the fundamental principle, that one should avoid shared mutable state as much as possible -- which is the upshot of the essay...

I think you missed the point. The OP is arguing that even non-shared mutable state should not be encapsulated away but should be accessible from some root data-structure. That way you can eg serialise the whole state of your program and restart it elsewhere or traverse the state with debugging and monitoring tools.

He points out that the traditional evils of global state (unrestrained mutation, non-reentrant code) have been solved in filesystems and databases and that those solutions could equally be applied to keeping state in-memory.

In other words, separate data from logic and keep all of your data in one place (whether that be a database, file-system or some well-controlled in-memory structure).


You missed the point, sorry. Awelon is about moving data like call stacks out of memory and into the database.

The contribution isn't the non-novel insight that mutable state is bad, it is that Awelon is attempting to actually solve the problem of how to remove "program state" from a program.


"Code quality matters when you have a team of people developing and maintaining software over a long period."

And for me, 'a long period' is anything longer than a month, or more specifically, the time period it takes for me to have to change any code I've already written in order to deliver new business value to a customer.

...and just noticed your 'six weeks' estimate. We're on the same page here it seems. :)


Been thinking about this a lot lately, and I think one of the problems is the language and metaphors we use to describe the quality of the code.

Words like 'clean', 'elegant', 'well-structured', even SOLID are qualities of objects we want to consider at a distance, like statues or paintings. They are words of repose and reflection. You know: business death.

Here's an example from this essay:

"There is a reason good code is considered to be a form of poetry. It's elegant, clean, easy to read, and fun to write. These are all exceptional qualities that we should strive for every single day."

Try telling a product manager or CEO or other stakeholder how 'clean', 'easy to read', or -- God forbid -- "fun!" your code is, and watch their eyes roll back in their head. (I exaggerate for effect.)

These ideas make sense to us as developers because that's what we spend our entire day doing: considering, reflecting and thinking about code. But I think what we should be talking about is the inherent speed of the codebase. I'm not talking about my velocity as a developer, or the velocity of the team and how many story points they deliver per sprint, but the inherent velocity of the codebase as a function of its technical debt. Codebases, from a business standpoint, should not be "clean" or "dirty", but rather "fast" or "slow".

Technical debt should be surfaced to the stakeholders using language that conveys the dollar value, the fiscal liability, of technical debt. The most accurate way to describe that and show how debt is slowing your team down, is to talk about its inherent speed.

"Our codebase is getting slower" makes business sense to a Product Manager. "Refactoring this will make our codebase faster" is a phrase that conveys the worth of initiatives that otherwise seem to have no immediate effect on the bottom line.

All of the tools and agile methods we have talk about velocity in terms of what a team is delivering, and can parse that down to the sprint and developer level. But in my experience, the most significant contributor to a team's relative speed is the (intertia|speed|velocity|momentum) of the codebase itself, as a function of its technical debt. I think we need to start using language that intuitively and constantly surfaces the dollar value of technical debt to the stakeholders, so that "just ship it!" no longer sounds like a sound business strategy.


This is a great idea. Thanks for sharing.

It's definitely much easier to convince people when you're talking dollars rather than "beauty" or "maintainability" which are much more abstract concepts. This pushes that to the forefront.

I wonder if anyone has experience with trying to use this language that they can share. I'm curious because it seems like a great idea. But I wonder if it would solve the "just ship it!" mentality. I still feel like there may be a missing component which is that what might be fast to build now will slow down the overall development effort later on. I think that time gap is one of the big things that stakeholders fail to think about. They're thinking "what can we get out the door now?" and not further down to what impact that will have on getting other things out the door a few months from now.

Great post!


Yeah I'm trying to get my head into how this would come about. It would be along the lines of how agile thought leaders shifted the notion of 'man hours' to 'story points', or how we stopped measuring LOC as a feature of productivity.

But there would have to be some cultural and language support for an entire idea around what a codebase is. The idea that it is an object that can possess the property of velocity will take a bit of enculturation. But the software/agile community has done it before, so...


"Codebases, from a busines standpoint, should not be 'clean' or 'dirty', but rather 'fast' or 'slow'."

This is pure brilliance. I can't express how much I love this idea.


Thanks! The more I think in this direction the more I think we need to really push this language or something like it. As much as I love the idea of 'craftsmanship', etc., when business stakeholders hear that language and similar ideas, fear grips their heart. We can do a better job creating awareness of the dollar value of bad code by changing the way we describe it in a credible way.


TIL Microsoft makes (a lot) more money on Android than Google does.


It's a reasonable question, but is it practical? 9/11 only killed a fraction of the number who probably died in the last few days in the recent typhoon, but the effect was to bring the entire country and economy to a halt.

The US would need statesmanship beyond that of Churchill to galvanize and harden society against those eventualities.

Moreover, in an era of dirty bombs, chemical weapons and even full nuclear devices, the consequences might not always be merely a "handful of casualties," and the grotesque effects of certain weapons, particularly on children, would be images that would be highly likely to incite increasingly aggressive responses.

The US historically is not a society that is accustomed to the idea of being under any kind of siege, nor of allowing its families to remain under threat of any kind. That's not the underlying narrative, and it's just not in its DNA.


I really don't think asking too much of our presidents to try an instill in the public the value of Liberty and Democracy; nor is this some Herculean task. It costs nothing, nor does it require a PHD from Harvard to explain, but it's an investment that will continue to pay off for generations without end.

As for Nuclear Weapons, Al Qaeda obviously does not have the technology to make them, so their safety is almost entirely a factor of international cooperation in regarding their security in countries that do. Such cooperation regarding their most sensitive and strategically valuable weapons requires trust, something that will be in shorter supply if we continue unhindered economic and political espionage.


It's unfortunate that we feel the need to lash out at broad categories of people, rather than finding and arresting the actual perps.

Of course, this is conveniently exploited for corporate smash and grab operations, and thus encouraged.


This is exactly the question. If the channels of democracy still exist in any form (and the alternative is unthinkable), then we have to take control of them and put forth real statesmen to answer this challenge. The consequence of failing to do so is a society that steadily descends into complacency and despair.

EDIT: BTW, I've no idea why your comment is not higher. Anyone downvoting it is not paying attention imo.


"If the channels of democracy still exist in any form (and the alternative is unthinkable), then we have to take control of them and put forth real statesmen to answer this challenge."

Of course the alternative is thinkable. History and politics and sociology classes are not that carefully censored and some people actually like the liberal arts. World history did not being with the US constitution and it'll go on past it, its already just a piece of paper as our leaders say, so I guess we are already in a post-constitutional era.

You won't be permitted to change things by voting. As has been said before, if voting could change anything it would be outlawed. You'll be given two choices, one who is in support of the NSA and says he opposes abortion but won't do anything about it, and the other who is in support of the NSA and says he supports a womans right to choose but won't do anything about it, because divide and conquer is how you control uneducated people, and no one is more uneducated than your average American, although there is a cultural goal to obtain training to obtain credentials to obtain a job to become a consumer.

The purpose of a democracy is to provide a tranquilizing influence on the masses once mass media exists, until mass media is conglomerated and mergered into only a few large controllable corporations. At that point democracy is not even needed as a soporific. This is the stage we're at now, confusion that we're subjects or serfs but not fully realizing it yet, just kinda confused.

This isn't just being grouchy or pessimistic; its a blueprint for the future. Want to know what will happen next election? Closest thing to a time machine ever invented? Read the above closely and guess what happens next based on it. History never repeats itself, but it does occasionally rhyme.


"History and politics and sociology classes are not..."

"its already just a piece of paper..."

"You won't be permitted to change anything..."

"if voting could change anything it would be outlawed..."

"You'll be given..."

"This is the stage..."

"The purpose of a democracy is..."

"its a blueprint..."

A litany of declarative bromides, delivered with pseudo-authority and strung together without forming a coherent thought, call to action or proscription for remedy. Such could only ever be pointless, nihilistic, and and anarchic.

Demagoguery in the making.


So what's needed is some kind of reform, perhaps ultimately leading to a sort of "Magna Carta" limiting corporate power over the US government.

Perhaps a first step would be working to get instant runoff voting in place to break the back of the two party system. That would go a long ways to offer more than a difference in noise about narrow social issues (e.g. - abortion, gay rights) which actually have little to no impact on broader economic issues or privacy issues regarding freedom from blackmail or other persecution.


"Such could only ever be ... "

You missed predictive in your list. A model resulting in falsifiable observationally verifiable prediction about the future, resulting in the model either living to fight another day, or being disproven. I'm optimistic about my predictions and model passing the test, how bout you?

Not liking the future results of the theory, doesn't disprove the observation or theory behind it.

Also the "its just a piece of paper" is a quote from a recent former president, not me.


The difference between your declarative and mine is scope. Mine focused on one person's statement; yours was a sweeping historical generalization.

"falsifiable observationally verifiable prediction..."

Go back and read The Open Society and Its Enemies or Objective Knowledge. and you'll find this statement constitutes a fundamental misreading of Popper.

Never mind the fact that Popper was basically wrong and the notion of 'falsifiability' is a non-starter when it comes to practical application of political theory, Soros notwithstanding.


Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: