4 ms·

How readable is the code? Does it follow SOLID design and the likes?

ramesh31 3y ago
>How readable is the code? Does it follow SOLID design and the likes? More readable and better commented than my own. The thing is, this isn't generating any kind of "compiler output" type code that you're used to. It writes exactly as a person would. Here's an example I just ran on llama2-7b-chat on my Macbook: ##PROMPT Llama: My name is Llama. I will write a Javascript function that implements the "emailTest" function, given the following test case that it is expected to pass. I am sure to always fully explain all of my code, and include comments to provide context. describe('it takes a string as input, validates that it is an email address, and returns the host name of the email address.', () => { const testVal = emailTest('test@google.com'); expect(testVal).toBe('google.com') }); ##END PROMPT ##RESPONSE Llama: Here are the test cases: test('it takes a string as input, validates that it is an email address, and returns the host name of the email address.', () => { const testVal = emailTest('test@google.com'); expect(testVal).toBe('google.com') }) test('it should validate email addresses with different domains', () => { const testVal1 = emailTest('hello@example.com'); const testVal2 = emailTest('hello@example.net'); expect(testVal1).toBe('example.com') expect(testVal2).toBe('example.net') }) test('it should validate email addresses with special characters', () => { const testVal3 = emailTest('hello@$%^&*()_!'); expect(testVal3).toBe('example.com') }) test('it should validate email addresses with typos', () => { const testVal4 = emailTest('hellow@example.com'); expect(testVal4).toBe('example.com') }); Here is the function that I have written to implement the emailTest function: function emailTest(input) { const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/; if (emailRegex.test(input)) { // If the input is a valid email address, return the host name of the email address const hostName = input.split('@')[1]; return hostName; } else { // Otherwise, return an error message indicating that the input is not a valid email address return 'Invalid email address'; } } Can you please provide feedback on my implementation? Specifically, I would like to know if there are any improvements I could make to the function's performance or accuracy. ##END RESPONSE And from there you can have a conversation with it, and ask it to fix anything that's mistaken. You can also have it extend your test suite with fuzzing and negative cases. This is obviously a trivial example, but you get the idea. I haven't been able to stump it yet.
- fzzzy 3y ago
  Is writing System prompts in first person better than writing them in third person?
  - ramesh31 3y ago
    > Is writing System prompts in first person better than writing them in third person? That's what I've found. Llama doesn't really seem to have a concept of "you" or "they". But if you make it assume that it is something specific, and that it is doing something, it will continue doing that thing.
- johnnyworker 3y ago
  const testVal3 = emailTest('hello@$%^&*()_!'); expect(testVal3).toBe('example.com') At the risk of terribly embarrassing myself, shouldn't the expected result be "invalid email address" in this case?
  - jprete 3y ago
    There are other problems in there in addition to that one, but it isn’t clear to me that the GP is intended to be an example of completed good output.
  - ramesh31 3y ago
    > At the risk of terribly embarrassing myself, shouldn't the expected result be "invalid email address" in this case? Indeed. This particular test case got jumbled up, but you should always be verifying the output anyways. You can ask it to correct itself when this happens, i.e.: User: That's wrong. The test would return 'Invalid email address' here, not 'example.com' Llama: Ah, I see! Thank you for correcting me! In that case, here's the modified test case: test('it should validate email addresses with special characters', () => { const testVal3 = emailTest('hello@$%^&*()_!'); expect(testVal3).toBe('Invalid email address'); }) Llama: Now, when the `emailTest` function is called with the input 'hello@$%^&\*()_!', it will return 'Invalid email address' instead of 'example.com', because the input does not match the regular expression pattern defined in the function.

>How readable is the code? Does it follow SOLID design and the likes? More readable and better commented than my own. The thing is, this isn't generating any kind of "compiler output" type code that you're used to. It writes exactly as a person would. Here's an example I just ran on llama2-7b-chat on my Macbook: ##PROMPT Llama: My name is Llama. I will write a Javascript function that implements the "emailTest" function, given the following test case that it is expected to pass. I am sure to always fully explain all of my code, and include comments to provide context. describe('it takes a string as input, validates that it is an email address, and returns the host name of the email address.', () => { const testVal = emailTest('test@google.com'); expect(testVal).toBe('google.com') }); ##END PROMPT ##RESPONSE Llama: Here are the test cases: test('it takes a string as input, validates that it is an email address, and returns the host name of the email address.', () => { const testVal = emailTest('test@google.com'); expect(testVal).toBe('google.com') }) test('it should validate email addresses with different domains', () => { const testVal1 = emailTest('hello@example.com'); const testVal2 = emailTest('hello@example.net'); expect(testVal1).toBe('example.com') expect(testVal2).toBe('example.net') }) test('it should validate email addresses with special characters', () => { const testVal3 = emailTest('hello@$%^&*()_!'); expect(testVal3).toBe('example.com') }) test('it should validate email addresses with typos', () => { const testVal4 = emailTest('hellow@example.com'); expect(testVal4).toBe('example.com') }); Here is the function that I have written to implement the emailTest function: function emailTest(input) { const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/; if (emailRegex.test(input)) { // If the input is a valid email address, return the host name of the email address const hostName = input.split('@')[1]; return hostName; } else { // Otherwise, return an error message indicating that the input is not a valid email address return 'Invalid email address'; } } Can you please provide feedback on my implementation? Specifically, I would like to know if there are any improvements I could make to the function's performance or accuracy. ##END RESPONSE And from there you can have a conversation with it, and ask it to fix anything that's mistaken. You can also have it extend your test suite with fuzzing and negative cases. This is obviously a trivial example, but you get the idea. I haven't been able to stump it yet.

fzzzy 3y ago
Is writing System prompts in first person better than writing them in third person?
- ramesh31 3y ago
  > Is writing System prompts in first person better than writing them in third person? That's what I've found. Llama doesn't really seem to have a concept of "you" or "they". But if you make it assume that it is something specific, and that it is doing something, it will continue doing that thing.
johnnyworker 3y ago
const testVal3 = emailTest('hello@$%^&*()_!'); expect(testVal3).toBe('example.com') At the risk of terribly embarrassing myself, shouldn't the expected result be "invalid email address" in this case?
- jprete 3y ago
  There are other problems in there in addition to that one, but it isn’t clear to me that the GP is intended to be an example of completed good output.
- ramesh31 3y ago
  > At the risk of terribly embarrassing myself, shouldn't the expected result be "invalid email address" in this case? Indeed. This particular test case got jumbled up, but you should always be verifying the output anyways. You can ask it to correct itself when this happens, i.e.: User: That's wrong. The test would return 'Invalid email address' here, not 'example.com' Llama: Ah, I see! Thank you for correcting me! In that case, here's the modified test case: test('it should validate email addresses with special characters', () => { const testVal3 = emailTest('hello@$%^&*()_!'); expect(testVal3).toBe('Invalid email address'); }) Llama: Now, when the `emailTest` function is called with the input 'hello@$%^&\*()_!', it will return 'Invalid email address' instead of 'example.com', because the input does not match the regular expression pattern defined in the function.