Thats a good idea. The current domain name registrar I currently use for my customers is iwantmyname (Recommended by fastmail). I asked them about this a few years back but they said they didn't have any kind of delegation system, but maybe I should check with them again.
Did you every have a problem where a customer got confused about the billing for the domain name? I'm pretty good a documenting the things I do regarding email and what needs to happen to keep there email system going, but I often get customers that have no idea about the billing when the domain name bill comes though to their email. They don't seem to remember that it has to do with there email account. Then they ignore the bill, their email goes down, they call me, I remind them that there email depends on a working domain name, they get there bill sorted out and the email gets restored. Some times this process gets repeated with customers that keep forgetting.
> In what job you don't need to worry about what code are you executing?
Worry about? Or understand the fine minutia of how every property you fetch or store is handled?
> It makes my job much harder to do, much more hidden and arcane
I don't know how you do your job, but seeing a real (i.e. not a faux property handled by __get/__set) class member's implementation is literally 1 click away in any decent IDE. Clicking to see the potential hooks of a field vs clicking to see the getter or setter (which may or may not even be defined in the same class) is no different.
> Yes, reflection is a mistake. It's a hotfix for problems caused by OOP. It's not actually necessary.
Right. I guess that's why it's applicable to functional programming. To be a hotfix for OOP?
For sure, it can be extended indefinitely. It's good that you made that clear. You can add a C compiler if you like (see Dusk OS) even, or a generic BNF parser generator (see Bradford Rodriguez) into "the language". Anything that you devise for code correctness, and static analysis can be added. My points about the lack of these language features were towards the previous comment about FORTH looking "more high-level than C". These are definitely major shortcoming for an inexperienced programmer to be able to do anything reasonably complex in FORTH (similar to using assembly).
> ... I would create a word that did something in a balanced way, test it quickly, and use that word instead to build on. Forth makes it easy to climb the levels abstraction quickly.
I would say any programming language with functions provide the same ease by that definition. That is, in each you can write a set of functions, than use them to compose higher level functions ad infinitum until you create a DSL as essentially a collection of functions for your problem space. Although doing so in C-like languages syntactically it may look more like Lisp than FORTH. In FORTH it looks more concise, and reads left-to-right thanks to it being accidentally a "concatenative language" with point-free notation and combinatory calculus roots. A great example of this being formalized is Joy by Manfred von Thun.
So I think what makes FORTH unique is more of the philosophy around it (again, see POL book by Chuck), which is a kind of zealous struggle for simplicity, but not easy, and keeping the problem in focus and not ignoring what's inside the boxes you build upon. You could say it's a panacea for yak-shaving if done right. Concrete examples for what FORTH does away in its search for simplicity and avoidance of yak-shaving, here are a few:
- no in-fix notation or ASTs: computers understand post/reverse-Polish by default by virtue of them being a stack(/register) machine, the programmer can do this work without major difficulty,
- no filesystem: blocks and table of block indices are enough most of the time,
- no floating point: fixed point is good enough for most problems,
- no classes, arrays, structs: you can build your own constructs suited for your problem as they are needed, there is no one size fits all solution,
Etc. The list goes on. Some of these are added into the so-called standards, but some argue trying to standardize FORTH defeats itself.
> The method that it uses to interpret/compile a word varies by implementation. Subroutine call is just one of them.
I used a vague terminology there, and should have clarified by saying "regardless of the threading model". What I meant was that effectively the FORTH source compilation is a one step pass that converts string tokens into series of "subroutine" (conceptually) calls that map 1:1 with the source code (homoiconicity); direct/indirected threaded, token threaded, or subroutine threaded all effectively is laying out/interpreting a series of subroutine calls, including those in FORTH CPUs like Harris RTX or GA144.
That will only hold while being watched is rare. See Clarke and Baxter's Light of Other Days for an examination of the consequences of ubiquitous surveillance.
To point out the obvious, film cameras don't, nor do many digital cameras. Unless you mean modern in the sense of "cameras you can buy from best buy right now", of course. But that isn't very interesting: best buy has terrible taste in cameras.
> Ultrathin meta-optics utilize subwavelength nano-antennas to modulate incident light with greater design freedom and space-bandwidth product over conventional diffractive optical elements (DOEs).
Is this basically a visible-wavelength beamsteering phased array?
Anyone who actually wants to be a hangman (or police, military, president, etc) should be immediately forbidden from applying for the job. The desire to wield power disqualifies anyone from actually wielding it wisely.
I'd like to see some examples showing how it does when taking a picture of completely random fractal noise. That should show it's not just trained to reconstruct known image patterns.
Generally it's probably wise to be skeptical of anything that appears to get around the diffraction limit.
> I invite anyone making that claim to find me an "advanced amateur" (as the article says of the LLM's level) chess player who ever makes an illegal move.
I would say the analogy is more like someone saying chess moves aloud. So, just as we all misspeak or misspell things from time to time, the model output will have an error rate.
I’ve also seen order of magnitude improvements going from both C and Java to Python (in the latter case also a similar reduction in memory consumption). It’s certainly true that CPython should be faster but I think we’re prone as a field to focusing on the cool compiler/language level Real Programming™ problems rather than dwelling on how inefficiently most programs are designed to be. The language matters, of course, but it also takes a certain humility to say we picked the wrong abstractions or spent time on the wrong parts, or that our expectations were shaped by microbenchmarks unlike the code we actually write.
I’ve lost track of how many times someone jumped to “ZOMG THE GIL SUCKS!!!!” but the real lesson turned out to be something like “maybe I shouldn’t open files in the middle of a nested loop”[1] or “the C extension used for dict/re/Numpy/etc. is actually pretty hard to beat”. One big problem for comparisons is that most of the time people don’t do a straight rewrite but change the algorithm based on the experience they got writing the first version - my Python beating C examples all fell into that category where it was really a refactor nobody wanted to do in a gnarled C codebase, or simply didn’t have time to make in a more limited language.
1. Someone I know ranted about Python, spent a month rage-porting to Go, and saw ~10% over the improved Python version.
So it has a chamber, a heater, a way to control chamber temperature. But its not a heated chamber because it does not have a single purpose heater vs using the bed for it? Sounds like semantics until testing is done.
That sounds harsh, and I don´t know the author, but I agree for sofar as I think that Python is in the PHP spot now.
The low barrier for entry is what they have in common. I remember that as a beginner everything outside my first language was a bit scary, so for some it is an emotional matter.
Trying to bolt on typing or making it a bit less "wasteful" is (although a fun exercise or probably necessary for some that have invested too much into it) ultimately a sign that you should move on to (dare I say) more apt ecosystems.
That is ok, part of growing as a developer. Just take with you what you have learned.
OK, but the LLM is still playing without a board to look at, except what's "in its head". How often would 1800 ELO chess players make illegal moves when playing only using chess notation over chat, with no board to look at?
What might be interesting is to see if there was some sort of prompt the LLM could use to help itself; e.g., "After repeating the entire game up until this point, describe relevant strategic and tactical aspects of the current board state, and then choose a move."
Another thing that's interesting is the 1800 ELO cut-off of the training data. If the cut-off were 2000, or 2200, would that improve the results?
Or, if you included training data but labeled with the player's ELO, could you request play at a specific ELO? Being able to play against a 1400 ELO computer that made the kind of mistakes a 1400 ELO human would make would be amazing.
the suggested solution seems to amount to 'functionally copyleft' for software distributions using the Rust name/trademark(s), and permissive licensing as normal in all other cases
sounds like a good solution to me, perhaps some concern about definition edge-cases
