I think Charles Babbage is a special case -- IIRC his son also picked up his work, after his death. So he actually worked on it for "generations", by having a child who also worked on his ideas :-)
Sure, someone at the bottom of the totem pole may not have autonomy to make decisions. There are others who can dictate policy. Is there no LG salesman who wants to take home this unit and becomes embarrassed about the behavior? A LG VP who might have this very unit on the desk?
The second day of owning this monitor and seeing the same message should be a wake up call to everyone in the LG product line to fix the annoyance.
This reads like Claude in its abstraction ... I'd rather hear the story about what degree you actually got, what the dissertation was, and some concrete experiences of being disillusioned along the way, etc.
Complexity becomes a way to postpone the verdict. etc.
Agreed. I think there is a much better story hiding under the surface but I wouldn't read a follow up because it's like Claude is holding them hostage for content.
Hm on first reading I was confused by the extern "fil-c" framing -- that seems to imply a bridge between C and Fil-C, which introduces some nasty language/runtime inter-op issues.
But I like this part
I want a Rust FFI that speaks the Fil-C ABI. ... We could use Rust for compile-time safety and then pay a performance penalty for using C.
Its' the exact opposite ... Google, nVidia, Amazon, Apple, etc. all have a deep bench of code that is a moat. They have lots of throwaway code too, but those companies are precisely the ones that pay attention to code quality, and comprehensibility by experts
A rough proxy for this would be if they say contribute to the C++ standards process, which Google Microsoft nVidia do, and basically zero "normal" companies (say SaaS) do. It means they are investing in multi-decade maintenance of their codebase
"Contribute" is an interesting word, since those companies are so big they can just dictate the standards they prefer. Also they are so big and have so much cash pouring in that they can afford to pay employees with nothing better to do than spend time drafting C++ standards. The average normal SaaS company is hoping they can make payroll next month.
Speaking personally, the fate of Docker, Inc. was clear to me when they took their $40M Series C round in 2014. I had met with Solomon in April 2014 (after their $15M Series B) and tried to tell him what I had learned at Joyent: that raising a ton of money without having a concrete and repeatable business would almost inevitably lead to poor decision making
This past July, we raised $25MM from A16Z and our existing investors, including Intel Capital and Dell. Recently, we raised an additional $70MM led by EQT Ventures.
Basically Scott Johnston is the guy that recoups money for investors, and in Docker's case, I recall that involved clawing back some value from users
From OP: As a shareholder of Fly.io, for this stage in Fly.io’s lifecycle, I liked his playbook better than mine. As the CEO of Fly.io, I liked the prospect of him doing all this work more than I liked the prospect of me doing it. We took a lot of time to work this out, and ultimately the board and I convinced him to take the job.
I think the intent is clear. We could just enumerate all strings in size and lexicographical order. Then the task is only to filter, which strings are programs we desire.
It's the same sentiment as "the typing itself is not the issue, it's the order of the button presses that's difficult."
Of course, by Rice's theorem, all interesting questions are undecidable anyway...
That is an unambiguous program that works in every shell. In a well-written shell program, the only things that should follow a single backslash in a double quoted string are
\ " ` $
(Although I found that this option is only on in ysh, not in shopt --set strict:all ... arguably that should be changed)
That seems to be be an entirely-different question - `echo "c:\\new"` still differs in behavior between bash and dash - dash parses backslashes in both the double-quoted string, and then echo does another backslash parsing pass, still printing a newline; whereas bash prints a backslash + n.
I am not sure this is a matter of "undefined behavior in POSIX" -- I think it might just be dash being wildly unconformant, which I have seen in other cases.
It's one of the least POSIX compliant shells. It is derived from the same codebase as busybox ash, but busybox receives more maintenance.
---
In any case, it is pretty sad that sh is in such poor shape than the default /bin/sh on Debian has different behavior in this basic case.
I built OSH to be a set of semantics agreed upon by many shells. I don't think any cross-shell test suites like our spec tests had existed in the past - https://oils.pub/release/0.37.0/quality.html
But there is little coordination among shell authors, and no real motivation to fix the gaps. In contrast, there is A LOT of coordination among JavaScript engine authors, mostly because there are people paid to work on them.
OK interesting, I knew about the -e -n flags issue, which means that any portable shell script has to use printf, not echo. Didn't quite realize that the use of backslash also forces printf ... what a mess
Here's how I deal with it using feature detection:
case "$({
printf %b "\\061" ||
print -r -- 2 ||
echo -n -e "\\063" ||
command -p printf %b "\\064"; } 2>/dev/null)"
in
1)
alias _printb1='printf %b'
alias _printn1='printf %s'
;;
2)
alias _printb1='print -n --'
alias _printn1='print -nr --'
;;
3)
alias _printb1='echo -n -e'
alias _printn1='echo -n -E'
;;
4)
_printb1 () { command -p printf '%b' "$1"; }
_printn1 () { command -p printf '%s' "$1"; }
;;
'-e 3')
_pdash () { _pd=$1; while :; do case $_pd in -*) echo -n "\\055"; _pd=${_pd#-};; *) break;; esac; done; }
_printb1 () { _pdash "$1"; echo -n "$_pd"; }
_printn1 () {
local _p _r
_pdash "$1"; _r=$_pd
while case $_r in *"$_BS"*) :;; *) false;; esac; do
_p=${_r%%"$_BS"*}
_r=${_r#*"$_BS"}
echo -n "$_p$_BS$_BS"
done
_pdash "$_r"; _r=$_pd
echo -n "$_r"
}
;;
*)
exit 1;;
esac
1) is for shells who have printf, 2) is for the ksh family, 4) is for PATH='' yash exclusively, -e 3) is for posh exclusively.
It exports two callables, _printb1 and _printf1 that escape and don't escape backslashes respectively, are immune to trailing dash gotchas and other pitfalls.
Unfortunatelly, not all shells allow overriding `echo` so I can't proper polyfill when necessary.
I'm going to extremes here, but a simpler version of this can be used for the most popular shells.
Personally I just write in the common subset of bash and OSH, which is very large. I never need to support say dash, since every machine that has dash also has bash, which is less broken in terms of 'echo' and so forth.
bash has its own broken-ness, but running under OSH solves that.
And OSH also supports some busybox idioms -- we learned last year that bash cannot run busybox ash scripts on Alpine
e.g. 'chdir' is an alias for 'cd' in busybox, but not in bash. And Alpine scripts use it, so bash can't run Alpine scripts, but OSH can (as of last year).
It's portable among the most popular shells, but much faster on dash. It's obviously a gimmick, but also a way to stress the interpreters past their usual breaking points.
osh fails at it because of multi-command/block-level alias (I opened an issue with a simplified reproduction).
---
Options are good. Shell is amazing at that, lots of interpreters to serve all kinds of users and use cases.
Additionally, the ksh family has `print`, which solves some of the issues.
And the story repeats all over again, each shell solving the problem in a different way :) That's one of the main reasons I went for solving the portability problem from the scripting side, not the interpreter side.
reply