jackcviers3

> You need to already know what you're doing to know whether the LLM got it right.

I want to call out that this is not necessarily true. You can interact with the LLM using agents, feedback loops, and some scoring function on randomized test inputs to produce novel code that you don't know the structure of beforehand.

You start with a set of example inputs and desired outputs, and prompt the llm for a function in your programming language of choice. You then take the LLM's response and feed it into an agent that executes the code against the inputs and outputs, and report the discrepancies back to the LLM. It responds with a new completion, which you feed to the agent until all your example inputs produce the expected outputs. Finally, you can use property-based testing to produce new examples for testing by the llm, resolving the answers until the produced code is correct to within some margin of acceptable correctness.

You can do this to produce code without needing to know anything besides the desired properties of generated code and the properties of the inputs. You can further automate this by using a separate LLM to produce the examples instead of the typical generation and shrinking functions to produce examples.

This doesn't require any prior knowledge of the target language. You can expand beyond programming into any domain for which you can produce a scoring function and automate input generation.

I suspect that you can use control theory (PID loops, behavior choice loops scored by Eigenvalues) to model complex scenarios spanning multiple domains as well, choosing the evaluation agent as the behavior, each behavior of which has a separately defined scoring function. All of this can be automated by using the LLM generator without prior knowledge of the algorithmic structure of the solution and knowledge of all possible inputs to all possible behaviors.

If that all sounds very familiar, it's because it's essentially just doing test-driven development, but with the LLM machine as the developer.

It would be expensive to run an entire project development that way, due to the high costs of executing LLMs and/or querying LLM apis, but if the cost is less than that of employing a junior developer or teams of developers, it might be worth it. And human intervention can be kept in the loop at any stage, making it very feasible for rapid prototyping - where you don't necessarily need the entirely correct answer from the machine, just a good enough starting point to allow the human to take over to produce a result.

Here's a thought -- TLD's shouldn't be coupled to countries at all and should just be a string pointer to an IP address. But that's none of my business...

I totally disagree. Ro optic probes are awesome, but their range of activity is extremely limited. They can stay on mission for years at a time in that limited area, but the ground you can cover with several manned missions is currently greater.

We've proven that we can keep humans alive indefinitely in space with the International Space Station. Expanding that practice beyond Earth's orbit can and will go a long way in advancing our understanding of our solar neighborhood.

The initial human explorations of the planets will be more limited than the rover projects. But I think we are getting very close to being able to mount much more significant investigations of our closest neighbors. We just need to choose to go.

Article made me nostalgic.

My very first job was writing streaming media services for radio. Integrating the ad services over events embedded into the stream identifying content was a pretty nifty solution. You send the metadata to your ad server, it selects the ads based on your user and media metadata, you swap out the player's media url to play the ad(s), and keep the stream going in the background. When the commercial break is up, you kill the ad stream and swap the media stream player back in. Presto changeo, seamless ads in 2007.

You also track media playback through the stream embedded events.

The hard part back then was live video/audio encoding. These cards lived at the stations, and streamed to our cdn. Geocoding for American service bases in foreign countries was interesting too, the streaming rights for stuff limits the countries you can stream in.

Monitoring the live encoders was an interesting problem - I setup an event-based solution so I could capture the audio waveform and analyze the frequency buckets on dozens of streams at once. Could tell if a stream was silent pretty quickly, and alert the station engineer via email.

Back then, a lot of this stuff wasn't off the shelf like it was today. Even on the frontend,working with Flash, window's media player sdk, and the QuickTime sdk and integrating it with Javascript was challenging. And the backends were all in php and Java 1.4, and mysql, and a whole lot of memcache.

Was a really great experience for a new professional programmer to write all that.

Perhaps it's an indication that humans are far more acceptable of risk in cars than they should be.

So you make:

    // new foo block 
    // using b:int stuff, 
    // calling fooInternalsX,
    // fooInternalsY, etc.
    // for common functionality
    foo(a: int, b:int) = ...

and

    // stays the same
    // except replacing
    // common functionality with
    // calls to fooInternalsX, 
    // fooInternalsY, etc. 
    foo(a: int) = ...

and enough

    private fooInternalsX(a:Int) = ...
    private fooInternalsY(a: Int) = ...

methods to cover the common functionality.

Your code is still DRY, and you are using polymorphism (foos of different type signatures) instead of if/else, the behavior of foo(int) doesn't change, so you don't require additional tests for foo(int), the fooInternals<X,Y,Z> aren't public, and you have now added tests for foo(int, int). You aren't paying any additional costs in terms of maintenance. You aren't increasing behavioral risk at C2 for calling foo(int). You are only paying more for foo(int, int), and those are costs that you would have to pay regardless of if foo(int, int) literally duplicated the body of foo(int) for common pieces or refactored the common pieces out. You save cost for maintaining both foo(int) and foo(int, int) if the common pieces need to change, as you are adding tests for the behavioral changes to both foo(int) and foo(int,int) tests, but are only making a single change in the common code.

Also, when doing this, the abstraction is the original foo(int), not the new, additional foo(int, int). Abstraction is the assumption of some parameterized behavior via hard-coding. Here, the new, additional parameterized behavior introduced by the second b:int parameter is abstracted away in the original foo(int), not in the new foo(int, int). That doesn't make the original foo(int) abstraction wrong, because it is used in at least one call site (C2).

Only when all call sites must change to accommodate something that a new parameter allows through more than one change-set can you begin to call an abstraction wrong. Otherwise, it is a simple bug that was fixed by a single change-set.

In the lexical closure doc example, why choose to show variable name shadowing? What is the purpose of `let x = 3` in the below?

let x = 3 func foo(x: Int) { fn inc() { x + 1 } // OK, will return x + 1 fn fail() { y + 1 } // fail: The value identifier y is unbound. }

`foo` also captures the global `x`, but shadows it with the parameter `x`.

Can `Generics` be generic - are there higher kinds? Are they all invariant, or do they have variance and if so what is the notation?

Maybe I missed it - can methods be destructured from structs? Can enums have methods?

Is there partial application for methods and functions?

Anectdote and opinion follow here.

As a nerd that did break out of that label, let me tell you that if you had any emotional intelligence or social skills, you don't lose social status in American schools for being smart, in science or any other subjects.

If you did other 'cool' things successfully - perhaps soft rebellion against teachers or administrators, music, athletics, parties, dance or cheer, or were physically attractive (took care of yourself and followed basic fashion), and had good social skills you don't stay at the bottom of the social ladder here, even in the Social Darwinism of middle and high school.

Competency and accuracy are the lowest form of interpersonal skills. If no other interpersonal skills or interests are cultivated outside of science, even the most competent and accurate individuals are likely to fail socially, which will also effect their career outcomes. Competency is used too often as a display of dominance or defensive mechanism. As bragging. As self-delusion. Connections with a diverse set of people outside of the competency only group will increase social skills and status, and with those connections comes a higher chance of success.

The people who are labeled nerds and derided for it constantly generally do not try or care to try to make these outside connections for fear of ridicule or oversensitivity, and occasionally physical safety. Non nerds see this as a superiority complex, and find overly sensitive and defensive people difficult. So they are devalued socially.

That is to say - make lots of friends and cultivate various interests outside of your core interests. Be interested in others and their accomplishments. Engage in the social jousting and own being the butt of a joke every once in a while. Don't lean on intelligence and academic achievement for everything. You don't have to win every debate to prove how smart and deserving to lead you are. You have more value than just being right all the time.

These values fit our American cultural ideals, where our leaders are typically selected on the basis of all their skills rather than a singular aptitude.

I think it is exactly as intended. As a developer of an open source project, you are not required to give your source code and _any other derivative of that code_ to _all users_. You are only required to give _each_ user the source code for what has been distributed to them.

Any user is free to turn around and _redistribute_ or modify anything that has already been distributed to them. The user is not required to distribute modified derivative source back to the original developer, unless the user has distributed a running copy of the derivative.

The license says nothing about not being able to _charge_ users for the original executable software. It says nothing about guaranteeing delivery of executable derivatives made by the original author in perpetuity.

In this way, the incentives are aligned to:

1. Produce useful running software that is of the same scale of usefulness and complexity of things such as Chrome and Windows, because these complex software packages have enormous value and cost time and money to make and should be profitable for the maker. 2. Also produce useful running software that the user is allowed to fix or build new, useful derivatives upon through receiving the source. For which they can then charge. Doing so, the original author may decide to not deliver any further derivative executables to the user, meaning that the user is no longer entitled to source code. The user now bears the maintenance burden for their entire product -- which, when distributed, must come with a copy of the source.

I think this allows for users to generate their own commercial value streams from the originator while protecting the originator's ability to make money, and I think it is a good thing. Open source work need not be volunteer work. You want updates, you comply with the terms of the license. You want to make a derivative work for your own profit and redistribute it, fine, but you'll have to renegotiate the price for the originator's updates to get the updates and the corresponding source updates.

Sounds like an excellent way for open-source devs to actually get paid for maintenance work, IMHO. It need not be free as in beer to provide value, and freedom, to users.

With smart lock services requiring hosting and registration and ip-block and cloud IOT expenses, I'm surprised that this isn't happening already to be honest. Also that per token issue fees aren't being assessed by open id or sso providers. They could especially game the system by decreasing the ttl of tokens to smaller durations, and by instituting load-based pricing .

"Write code that writes code" -- Tip 29, The Pragmatic Programmer[1]

I think we need to be a little more nuanced, here.

Don't be clever in your code generation, to be sure. But let's not act like you need advanced degrees for all meta-programming.

What do you think phased compilers do? They generally transform the AST produced by your code into expanded versions or rewrites of that AST that are more amenable to machine interpretation or transformation into assembly.

In a very real sense, nearly all production code goes through some kind of codegen process. It isn't clever, it isn't new, it generally isn't complicated (if this then that else that else ... when you get down to it). It is repeatable and reproducible and reliable enough method that the whole economic system of software is built on top of it. Most of the problems come with recursive applications of codegen and strange interactions between different subsystems of codegen.

Here's a tip: Don't do recursive codegen in your user land metaprogramming.

User code is _easier_, simply because it isn't as reusable as the language primitives themselves. But if you understand a problem well enough to essentially reduce it to copy, paste, and replace one or two items, codegen is superior because a bug fix during maintenance need only happen in a single place.

My primary language recently added generic derivation to the language itself (as opposed to in macro libraries) and it is totally worth it as I almost never have to write a ser/de by hand. I never have to test the ser/de round trip. I don't have to pepper my code with second-class annotation primitives or keywords. I never misspell `asJson`, etc.

Not everything should be done with codegen in user land code (code outside the compiler and language tooling). But if I see thousands of lines of json/avro/protobuf/test example copypasta, that's a code smell that needs to be addressed or it will lead to production bugs and take hours instead of minutes to fix.

And when you write these things, you come to find out that they are just like any other data transformation task. They turn `A`s into `B`s, systematically.

My mentor, when I became a professional coder, taught me that if you do something more than three times, its probably worth taking the time to generalize it and do it once before you push the changes into the version repository. It's been 18 years now since I began my career, and that simple principle has rarely steered me wrong across probably a dozen languages that I've written production code in.

1. https://www.goodreads.com/book/show/4099.The_Pragmatic_Progr...

Probably needs its own extension like in vscode.

Use helm-M-x and which-key, and avoid anything but use-package and customize. You don't have to eat the muscle-memory elephant all at once.

Modern features:

1. lsp-mode/eglot

2. package management

3. treesitter grammars

4. Portability - win/linux/mac/unix/android

5. Graphical User Interface - you can browse the web and watch YouTube in Emacs. Customize has buttons, forms, menus.

6. Treemacs/Treeview/speedbar: you know the multipanel view in Intellij or the project explorer in Intellij/vscod? Yeah, that.

7. Actual macros and function definitions, without needing to post them as an extension.

8. Interactive repl.

9. 5 different terminal emulators built-in.

10. Automated fuzzy everything with helm-M-x and helm. Exactly like Command-p in vscode.

11. github, gitlab integration with magit.

12. Copilot, tabnine, and chatGPT integration.

13. Hundreds of themes.

14. We've had shareable, secure remote collaboration for over a decade with wemux.

15. Use any ttf.

16. Mouse editing and command binding.

17. Use every build tool with projectile-compile-project.

18. Refactoring with lsp.

19. Autocompletion and jump to source.

20. Session save and restoration with desktop-save.

21. Slack integration.

22. Debugger with dap-mode.

23. Individual test only runs with dap and avy-lens.

24. blame with.magit-blame.

25. Pixel scrolling.

25. Transparency with seethru.

28. Rest client with variables and session storage (like postman, but free).

29. Browse compressed files as if they are normal directories and save to them.

30. Containerized deployment via flatpak.

31. Docker, docker-compose integration, kubernetes, aws, datadog, Azure integrations...

All of this fits in around 500 lones of copy_paste/cloneable emacs configuration, most of which is use-package declarations. Nary a defun or global-bind-key in sight, and because emacs is a full elisp ide, and it is actually executable code, it's debuggable on launch, unlike myriads of json files.

I'm trying to think of anything else that can possibly be interpreted as 'modern' from a ux standpoint. I certainly can't think of a feature that Intellij has that emacs doesn't that is core to the ide experience. And most of my emacs tools are better than the vscode version of them, at least in terms of invasion into the editor buffer or integration with the editor ux.

The one thing that's not modern is the standard copy and paste commands, but that's super easy to customize. I guess you can't drag and drop buffer frame borders in multiple buffer layouts if you hide scrollbars, and the message buffer isn't resizable...

One simple and relatively cheap way Phoenix could be more survivable would be to build underground.

The temperature at 12 feet below ground or more really doesn't change much throughout the year.

The reason they don't do that in Phoenix is that they don't need to dig foundations because there isn't any frost rise or fall at the surface. Since that is the case, the extra cost of digging a basement, which is around 3%, cuts into the margins of large home builders enough that it isn't done.

They could also drill into the ground even deeper and use it as a heat sink and pump air through pipes to cool homes. Again this is more costly at construction time, though it would save money for the homeowner and provide protection for the city in gear emergencies, and put less pressure on the power grid.

Finally, every home there should have solar on the roof to offset AC charges, and a passive dew condenser to provide extra water for the house. They don't.

There appears to not be that much diversity in facial structure, body types, clothing styles, color, sex gender identity, ethnicity, setting, perspective or culture in the human beings present on that page.

This leads me to question the AIs training biases and capabilities to generate truly representative art depicting the human experience with the tool.

It also represents author biases, of course.

I disagree with the second slightly, because we have a very limited amount of time in which to produce things that matter, and we spend the majority of that time producing code as developers. It better be important to us, or we should be doing something else.

Now, what we should realize about the code isn't the thing of value. It's what the code does and how it does it, that is the runtime output and the ability to express the intent to produce that output to a programmer who hasn't seen the output or the code before or in a long time.

Criticism is the best opportunity to improve those aspects of the code you write. So it should be of equal value to you as the lines of code the criticism is addressing.

Not all criticism is valid, even well-intentioned constructive criticism. Experience teaches you which critiques to accept and which to reject.

The only way to gain that experience is to solicit criticism from others, and give it to others.

No, we are not just our code, but our artifacts are a part of us, as we are a part of them. So we should be kind when giving criticism and gracious when receiving it. Because what we choose to do with our time matters.

Can you do cross-platform builds on it with buildx on M1 yet? What's the story around shared volumes? How about local registry running? Will it work with DB test containers in Java? How about Java clients that use the docker socket, like maven's docker plugin?

It exploded when trying to orient for the first stage separation. And it appeared to have 5 of the 33 engines out during the first stage flight. This launch gave me very "Don't Look Up" ending vibes.

Going to need some citations on this claim. Also, how is a person supposed to market one's experience for a job interview if they don't say what they've done? And the comparison between older engineers and gorillas isn't a great look, either.

It is a direct visualization of churn. You can really tell when some area of the codebase changes every single day. Probably means that you need to break whatever is attracting all the attention apart.

Most of the studies I can find on Google show that remote employees are more productive, and that management trusts remote employees less, despite more productivity.

Why are companies so interested in RTO, when the data seems to show that remote work is more productive? It seems like traditional management needs new training to sustain remote productivity gains, not that remote work should be discontinued to increase managers' trust in their employees.

This. And if you look at the level of algorithms knowledge needed today to read the least amount of data from a set, it succeeded.

This is how I use it. It is the best rubber duck money can buy.

I firmly believe that we should be studying model analysis and using that to create a field of peompt engineering. Both from a security standpoint and a productivity standpoint.

This. At the end of the day, if it is a significant transfer there are people in locked rooms that have to call each other and independently verify a transaction brokered by a third party. And if you don't pass a background check, and don't need to be there, you don't get in that room.

Reply to Grandparent and this: Very cool and definitely useful to record and replay the session and modify breakpoint conditions for replay. I wonder if session recording like this could be safely brought to backend systems. You'd almost have to stub every remote call to allow for replayability in isolation of external services, and the potential for data leakage from a downloaded session is also a concern. I'm glad someone else is working on problems and tools like this.

I should note I'm not disparaging the use of debuggers in my comments, but lamenting the nature of the process of debugging the types of systems we deploy today, and the largely non-interactive nature tradeoffs we've made for scalability, reliability, availability, and operability. Sometimes I long for the simplicity of a fully self-contained local system, but I know we just don't live in that world anymore, and haven't for a long time now.

I've worked on a lot of sophisticated data pipelines, in robotics, built customized wysiwyg editors, distributed systems, append-only logs with replicated data types, in around a dozen languages. While I have found occasionally remote profiling useful for optimizing hot code paths, I have always found that trace-level logs and structured logging with aggregation and indexing is superior to debugging in most applications.

Essentially - println debugging is superior to interactive debugging, especially for intermittent bugs, data races, deadlocks, resource leakage, modeling and serialization bugs, binary or source code incompatibility bugs, and bugs that are catastrophic and rare or pathological in nature.

The problem with interactive debugging is that you typically only have a view into not only a single process of a system, but also only a single concurrent execution thread of the single process.

When you have structured logging and aggregation and indexed log search, you have a much broader view of the systems under investigation and can see the conditions causing the bug with a much higher frequency than with interactive debugging.

For any non-trivial bug in any sufficiently large input or program you have to have insight into the root cause via intuition to cause it to occur quickly enough to inspect the program via the debugger. This obviously doesn't scale well. It's much better to have a detailed, structured log mode built into your systems that is capable of being enabled on demand - via environment variable, remote procedure call, request header, data packet, or command flag during deployment. This allows you to observe the system behavior and incur the cost of the detailed logging on demand, much like you would when connecting via remote debugging, but on a system of systems scale, increasing the probability of capturing the bug's root cause over stepping forward and backward through interactive execution.

Additionally, care should be taken to program in a value-centric way when you can get away with it performance or space-wise. Essentially - use FP principles of immutability and programs as values and composition to build your programs where you can. Values have a unique property in that they are serialization state that can be inspected or substituted in place of references to the value without changing the behavior of a program at runtime. This often simplifies debugging even in complex side-effecting concurrent algorithms.

When you can't, comprehensive argument and shared state change log events that can be shared amongst many members of the development, stakeholder, and operations teams asynchronously helps to narrow the surface area scan of the system you are debugging.

Formal methods during modeling, design, and development can help to increase constraints and enable more comprehensive test suites, but property-based testing with randomized generated valid inputs also serve as a sort of automated preemptive debugger. Things like chance in the js world, quickcheck/hedgehog in haskell and their ports or siblings in other languages, like hypothesis in Python, fall into this category of testing tools.

Interactive debugging is the tool of last resort, and still serves a useful purpose when all other mitigation and system state capture methods have failed, but I personally find myself believing that if a bug's root cause hasn't been discovered by this stage I have made some set of mistakes in the design of the system, either in the application of its logical rules or in the basic assumptions fom interpretation of business requirements to the choices of abstractions/tradeoffs made in development. It's usually a bad day when I have to resort to interactive debugging.

I live in Iowa. Apparently it's still legal here:

> In 2010 in the case of the State of Iowa vs Christopher Spates, the Supreme Court judge Justice Ternus states that Iowa only considers the mutual combat law if two combatants agree to the use of deadly weapons, so you can see how different the law varies from state to state.

https://law.justia.com/cases/iowa/supreme-court/2010/05-0883...

I wonder if the state would actually adhere to that judgement again.

Mutual combat laws apparently exist in many U.S. states - Texas, unsurprisingly, is one of them too.

A possible counterassumption:

You are on low-priority projects because you aren't trusted on high-priority projects or have been out-maneuvered for them by other senior team members, or don't have enough political capital to convince others of the importance of your project to make it high-priority.