Live data from Hacker News

StableCode

stability.ai

101–109 of 109 posts

Re: StableCode

#101

> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…

The audience for this is management. They'll spend lots of their budget on it. They'll use this to put something together that does something, just not what they want. Then they'll show it to you and tell you to make it work the way they think they want. After all, if a manager can "do it" in 90 minutes with no training a developer should be able to make it perfect in a few days. And they'll make you use the new tool so you learn it and so they can justify the expense.

Re: StableCode

#102
post #54

> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…

The reason that people need to gather precise requirements that are precise is because the specifications -> product loop is long. Imprecision results in lots of wasted effort. If that loop is shortened drastically, then trying, checking and tweaking is suddenly a much more viable design method. That doesn’t require a precise set of requirements.

A better tool to improve production would be an expert system that would gather requirements. But the people who want software to do their job either can't specify what they do or don't want to invest any of their time in what they see as someone else's job.

Re: StableCode

#103
post #53

> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…

It’s about giving the domain experts who understand what the requirements should be a way to build something without having to have the domain knowledge of code.

Sorry, but in my experience fish think about water more than domain experts think about requirements.

Re: StableCode

#104
post #91

Earlier quoted context omitted.

There's also just far more tokens to train on if you do multi-language. I'd guess only the most popular languages would even have enough training data to get a specialized version - but it would still be an interesting trade off for certain use cases. Being able to run a local code assistant on a typescript-only project for example, with a 32k context window would really come in handy for a lot of people. I don't kno…

Its worth noting that from what I can tell - A model well trained in most languages would be able to learn the niche ones much more easily. The vocab size of llama2 is 32,000. I guess I personally don't think that there's enough difference in programming languages to actually save any meaningful number of tokens considering the magnitude of the current vocab.

I wonder if you could train a model generally across a lot of languages, then specialize for a specific one with a different tokenizer / limited vocabulary? Here's the reference I've been using for llama 2 tokens:

https://huggingface.co/mlc-ai/mlc-chat-Llama-2-7b-chat-hf-q4...

it looks like if you just limit it to English it'd cut the count almost by half - further limiting the vocab to a specific programming language could cut it down even more. Pure armchair theory-crafting on my part, no idea if limiting vocab is even a reasonable way to improve context handling. But it's an interesting idea - build on a base then specialize as needed and let the user swap out the LLM on an as-needed bases (or the front-end tool could simply detect the language of the project). 3B or smaller models with very long context which excel at one specific thing could be really useful (e.g. local code completer for English typescript projects)

Re: StableCode

#105
post #96

If I’m reading this correctly this could be an open source model that may compete with the likes of copilot? That is something I’d be very interested in if they can get the compute requirements down to those of say a standard 13B model. Then I could fine tune (correct term?) it on my offline data and hook it into something like fauxpilot and my IDE. I had a look at some of the recent code models (wizardcoder,strider…

Trained specifically for Python*

Re: StableCode

#106
post #50

Earlier quoted context omitted.

in what world is a hashtable lookup worst case O(1)? Your own solution doesn't match your requirements. If you want amortized complexity then a simple vector suffices.

1. I like toxic comments like that saying something is simple without actually solving the problem, you're the best. 2. The average complexity to search, insert, and delete data in a hash table is O(1), for interviews it works 99% of the time. 3. There is alternative O(1) solution you're looking for, I'll leave this exercise to you, bro. As well as the other exercise of being less toxic and a bit more respectful to p…

Pointing out a mistake is toxicity? Your ego is off the charts. Also, I gave you a solution that would probably be _better_ than yours in 99% of scenarios, a simple vector from any standard library, std::vector in C++, and Vec in Rust. This solution gives you O(1) worst case for peek, and amortized worst case O(1) for the other operations.

To be actually toxic for a moment, you do know that amortized and average are different right?

There is an easy solution to get O(1) for all operations too by allowing them to throw an exception: a simple array. There is no other O(1) solution for all operations that I am aware. In fact it is probably not too difficult to prove that such a solution does not exist.

Re: StableCode

#107
post #66

> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…

You're missing the point: Natural language can be much a higher layer of abstraction than the programming languages we currently have. It's much faster to say "Add a button to download the output as a PDF" than write JS directly. You'd be surprised by what regular people can build when you give them the power to create software. Here are a bunch of apps created using my tool/GPT-4: https://showcase.picoapps.xyz Most…

Hence, the usefulness of tools like UI.Vision RPA

Re: StableCode

#108

Earlier quoted context omitted.

1. I like toxic comments like that saying something is simple without actually solving the problem, you're the best. 2. The average complexity to search, insert, and delete data in a hash table is O(1), for interviews it works 99% of the time. 3. There is alternative O(1) solution you're looking for, I'll leave this exercise to you, bro. As well as the other exercise of being less toxic and a bit more respectful to p…

Average and big-O notation don't go together... Yes, it works 99% of the time, but parent explained to you why you won't get that 1% of the offers. That, plus taking offence by his comment, which makes you not pass behavioral part of the interview.

> which makes you not pass behavioral part of the interview

I'm okay not getting 1% of the offers. I'm not $100 bill so everyone likes me.

I appreciate an attempt to educate me though, I wanted to make clear that any discussion like that is useless without solution to a problem. Post your solution, we'll discuss downsides. You can see it from my side, and I have another one. The parent commenter ain't got no solution, but keeps insisting he can implement that easily with this and that...

Good luck passing interviews with that attitude...

Re: StableCode

#109
post #106

Earlier quoted context omitted.

1. I like toxic comments like that saying something is simple without actually solving the problem, you're the best. 2. The average complexity to search, insert, and delete data in a hash table is O(1), for interviews it works 99% of the time. 3. There is alternative O(1) solution you're looking for, I'll leave this exercise to you, bro. As well as the other exercise of being less toxic and a bit more respectful to p…

Pointing out a mistake is toxicity? Your ego is off the charts. Also, I gave you a solution that would probably be _better_ than yours in 99% of scenarios, a simple vector from any standard library, std::vector in C++, and Vec in Rust. This solution gives you O(1) worst case for peek, and amortized worst case O(1) for the other operations. To be actually toxic for a moment, you do know that amortized and average are…

If your interviewer is asking for solution and you keep insisting that "I have you a solution"... without actual code... Also saying my ego is off the charts. Good luck passing interviews with that attitude.
Post reply on HN