> A separate document explaining how a system works can go out of date.
Good documentation does not explain "the how", it captures "the why."
3,750 karma · joined June 16, 2015
Good documentation does not explain "the how", it captures "the why."
Maybe. More likely is there are AI bots used to proliferate messages much cheaper than "paid posters."
> Why would anyone defend a billion dollar corporation so vehemently and not earn a single dime?
Because some like the products made by said billion dollar corporation?
Because others like to be contrarian?
Because not everyone is motivated by being paid?
Maybe, just maybe, people are different and have differing motivations not easily reduced into being "am I getting paid for this or not."
> I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier.
Here is my corroboration. Apple publishes XNU to the world in this repository:
https://github.com/apple-oss-distributions/xnu
> I do think there is an argument to be made that Win32 was more straightforward ...
I did not make that argument. Instead, the position I hold regarding Windows is:
... an independently derived emulation layer is
possible (not easy, just possible) ...
In fact, you have made my point for me:
> ... while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used.
Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.
The former lends itself to intrinsic portability such that an independently derived emulation layer is possible (not easy, just possible), whereas the latter has the freedom of assuming device capabilities/features always present for any given release.
Call it "intention", call it "understanding", call it "effective communication." The lack thereof is obvious and easily identified.
> Most success stories of LLM coding are ports. Because someone already did most of the job with the original code, sometime even twice if we count the tests.
Another way to phrase this is:
Because someone already thought about the problem and what
needs to exist in order to solve it.It is a technical thing.
The XNU[0] kernel, which underpins macOS and is detailed by the exceptional book "Mac OS X internals"[1], can theoretically run on many x86 and/or ARM machines. However, the issue with running macOS apps via other operating systems is not the OS, but instead are the GUI frameworks expected (i.e., Carbon[2], Quartz[3], etc.). These frameworks are intentionally written for Apple hardware/macOS distros. Which makes sense when viewing macOS as a selling point for selling Mac's.
0 - https://en.wikipedia.org/wiki/XNU
1 - https://openlibrary.org/books/OL17205558M/Mac_OS_X_internals
IMHO, both approaches have merit depending on the situation. I lean towards using SWIG until and unless the situation warrants a hand-written solution due to the boilerplate nature of these types of libraries.
And those reasons are?
SWIG[0] makes working with C libraries trivial for over a dozen programming languages; Perl, Python, and Ruby included.
> Somewhat more meaningful was "INT 19h" (CD 19) ...
I seem to remember the smallest MS-DOS program to be CD 20h saved as a `.com`.
LLM poisoning[0] would be a much greater risk in a locally executed LLM than prompt injection, given that the LLM would be in an entirely controlled environment.
What is the best chicken noodle soup I can make?
Ask a person the same question and you might be told:
One you make for someone you love.
It is because GenAI output has no thought behind it, as you identified in your previous paragraph:
> And when I force myself to read AI-generated text I realize I'm making my brain do creative work to impart meaning to the words. It is exhausting because my brain is literally trying to do a just-in-time rewrite of the text into something valuable.
You are searching for meaning in something which was not created to convey meaning. The text was, instead, the result of an extremely clever statistically based algorithm.
Not contemplation. Not thought.
Understanding.
LSPs are orthogonal to both LLMs and VSCode. For example, see Metals[0].
And for some front-end form field validation in the spirit of htmx, ParsleyJS[0] is quite nice. Below is one way to enable the former to support the latter:
htmx.defineExtension (
'parsley-validation',
{
onEvent : function (name, evt) {
var allow = true;
if (name === 'htmx:load')
$(evt.target).parsley ();
else if (name === 'htmx:confirm') {
var theForm = $(evt.target).parsley ();
theForm.validationResult = allow = theForm.isValid ();
if (!allow)
evt.preventDefault ();
}
return allow;
}
}
)
Those were not "DOS-based Windows". If your position is Windows/386 et al were OSs which supported running MS-DOS programs, I agree. But that is not "DOS-based" so much as "can run DOS programs."
I laughed at the thought in the moment and now understand the wisdom shared with me.
0 - https://en.wikipedia.org/wiki/Lisp_(programming_language)
> However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go.
This is an exceedingly charitable interpretation of the position held by at least one Go language designer (Rob Pike)[0]:
Notice that Robert said C was the starting point, not C++.
I'm not certain but I believe he meant C proper, especially
because Ken was there. But it's also true that, in the end,
we didn't really start from C. We built from scratch,
borrowing only minor things like operators and brace
brackets and a few common keywords.
In the end of course it came out quite different from
either C or C++. More different even than many realize. I
made a list of significant simplifications in Go over C and
C++:
...
- no templates
...
That is a very selective quote which does not reflect the context I provided. So I will extract a selective quote which negates the above:
We haven't yet found a design that gives value
proportionate to the complexity ...As the old saying goes; just because you can do something doesn't mean you should do it.
> I think that the "use Postgres for everything" messaging was a necessity, even if it is overstated. Use it until you can demonstrate it doesn't meet your near term needs. When that happens, shift.
The problem with this approach is, once "use PostgreSQL for everything" is identified as being no longer be feasible, it has already become an inextricable component underpinning system functionality. Thus making "[w]hen that happens, shift" extremely difficult.
Contrast the above with only using PostgreSQL (or any other RDBMS) to manage data and their relationships, eschewing stored procedures as well, and the "when <insert condition> happens, shift" decision becomes much more feasible to entertain.
This is provably incorrect.
The position held for many years by the language authors was[0]:
Generics may well be added at some point. We don't feel an
urgency for them, although we understand some programmers
do.
Generics are convenient but they come at a cost in
complexity in the type system and run-time. We haven't yet
found a design that gives value proportionate to the
complexity, although we continue to think about it.
Meanwhile, Go's built-in maps and slices, plus the ability
to use the empty interface to construct containers (with
explicit unboxing) mean in many cases it is possible to
write code that does what generics would enable, if less
smoothly.
The Go 1.18 release added type parameters to the language.
This permits a form of polymorphic or generic programming.
While the GP may have been referencing the former, embracing "PostgreSQL for Everything" often prohibits the latter.
"DOS-based Windows" was not an OS. It was effectively a program which provided a green thread[0] execution model for cooperative processes to execute within and had the reliability one would expect from same.
It's funny that you and many others have found the introduction of "generics" in Go to be highly valuable, considering one of the motivations for Go's existence was:
Its designers were primarily motivated by their shared dislike of C++[0]
DDJ: In the presentation before the awarding of the Japan
Prize today, you were quoted on the distinction between
reasearch and development. [The former, Thompson stated,
was directionless, whereas development had a specific goal
in mind.] So in that context, is Go experimental?
KT: Yes. When the three of us [Thompson, Rob Pike, and
Robert Griesemer] got started, it was pure research. The
three of us got together and decided that we hated C++.
[laughter] [2]
0 - https://en.wikipedia.org/wiki/Go_(programming_language)#Hist...
1 - https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
2 - https://web.archive.org/web/20110521080746/http://drdobbs.co...
> It was never OS-X, it was OS X ...
If my worst sin is an introduction of a hyphen, then I can live with that.
I still twitch whenever someone says "use ddd" and they are not referring to Evans' seminal work.
:-D
A similar "brain drain" has occurred in macOS (formerly known as OS-X) over the years, as evident in man page documentation for "newer" daemons shipped. An easy way to verify this is to run:
ps -A | awk '{ print $4 }' | grep 'libexec/.*[a-z]d$'
While this exercise is illuminating, it is also depressing IMHO.
I also have worked on/with expert systems.
> I don't agree that they achieve "simulated intelligence". They're preprogrammed with a set of domain-specific rules that are trivially simple by comparison to even relatively simple and small neural networks.
This position does not account for fuzzy logic[0] nor an expert system's ability to produce an answer of "I do not know and here is why", which neural networks are incapable of doing.
I am not saying expert systems are "better" than ANNs as both are algorithms having significant value for what they provide. What I am saying is neural networks are pattern-matching algorithms, quite useful in their own right, and do not possess the ability to identify the lack of existence.