GitHub Spark lets you build web apps in plain English | Hacker News Reader

GitHub Spark lets you build web apps in plain English

techcrunch.com

97 pointsdavidgomes54 comments

On the one hand, it's impressive that they've apparently built a general-purpose LLM interface for this. On the other hand, even before considering LLM limitations, trying to define app behavior of any complexity using plain language is a great way to get a buggy and inconsistent mess.

Yes, even when we get designs that passed multiple rounds of user interviews, even after developers went over them and approved and estimated work, we still end up finding undefined behaviors while coding it.

We would need AGI-level AI to code software from English and not produce buggy mess.

On the other hand, current top LLMs are pretty great at writing chunks of code if you specify exactly what you want. I am personally impressed with Claude 3.5.

I would also find developers who could take the slightest vague term, misunderstand it in a 'technically correct' but to everyone else, outrageous way.

To counter this I used to hold short meetings with them every single morning to pull them back into line! We also shortened every build into bite sized chunks so the humans could check they didn't go off-piste. We called this Agile.

Poor communication between humans is seemingly insoluble. Perhaps a computer misunderstanding you in real time so you can correct is the best solution?

Comms is a Hard Problem, but specs should not be regularly ambiguous that they require daily course correct - huge velocity killer.

Exactly. Even when building websites for clients they often ask for mututally incompatible things within the same sentence, and there's often hidden complexity buried in the most innocuous-sounding sentences.

Indeed. This one reason why when humans describe what they want from their software, developers build something entirely different from what was requested.

Perhaps this shortens the cycle time?

I feel like syntax actually helps in writing unambiguous logic. Doing away with syntax and writing in plain English might sound nice to someone who is just starting to learn how to program and it's tired of not understanding syntax, but I feel like doing away with syntax is really doing a disservice to any actual application development.

But then it turns into writing in a programming language, which is the opposite of the goal of the project.

Yeah, what I'm saying is I'm unconvinced that this goal is a good idea to begin with. Even if executed perfectly, I don't think it will be able to compete with programming languages for the purpose of programming.

Right, English is just a plain bad way to tell a computer to do something. The signal to noise ratio is too low and references are too ambiguous.

You see this with the ridiculous "prompt engineering" crap that has sprung up where people are slowly reinventing programming languages but completely unspecified. Something that could be specified in 4 lines of godforesaken YAML ends up taking 40000 words of very bizarre English and using enough energy to roast a whole pig.

> Doing away with syntax and writing in plain English might sound nice

Welcome to the world of lawyers. That is exactly what they are doing all days and the outcome is a mess.

Whether it's a namespace collision or not, it's uncool of them to steal the name of Apache Spark, which was an influential project in machine learning, and must have helped generative AI get to where it is today.

Wouldn't be the first time Microsoft (And other big corporations, anyone remember Apple iOS vs Cisco IOS?) behaves this way [0] . I'm sure there are more examples out there.

[0] https://itsfoss.com/microsoft-maui-kde-row/

Another was Microware OS-9 getting stomped on by Mac OS 9 because the much bigger company had the right to whatever it wanted.

I think "Brand X Spark" is OK. It's not exactly an uncommon word.

- Adobe Spark https://express.adobe.com/page/dRGX7a5xjEnh5/

- Meta Spark https://spark.meta.com/

- Spark Mail https://sparkmailapp.com

- Spark New Zealand https://www.spark.co.nz

- Chevrolet Spark https://en.wikipedia.org/wiki/Chevrolet_Spark

- DJI Spark https://www.dji.com/support/product/spark

- Spark Racing Technology https://www.sparkracingtechnology.com

- Capital One Spark https://www.capitalone.com/small-business/credit-cards/spark...

- Spark Therapeutics https://sparktx.com

- Spark Energy https://www.sparkenergy.com

None of those is anywhere near the ballpark of similarity that Apache Spark is in.

I think that's the point

"None of those" refers to everything in the bulleted list in the comment I replied to.

The one that I think Apache Spark is similar to is GitHub Spark, because they're both developer tools, and AI adjacent.

So Laravel Spark is also a problem?

It's not like both Apache and GitHub just called it "Spark".

Apache Spark. GitHub Spark. Brand-name Spark. I think that's fine.

Apache Spark casually gets called Spark, and it especially gets called Spark when referring to subprojects. For instance there's Spark Core, Spark Streaming, and PySpark. https://en.wikipedia.org/wiki/Apache_Spark

BTW the trademark: https://spark.apache.org/trademarks.html

The wording of this does imply they've trademarked the word Spark, but that really doesn't sound likely.

Trademarks are automatic when certain criteria such as usage in commerce are met, at least under the statutory or common law of most/all US states and some other countries with English colonial histories; certain US federal protection under the Lanham Act can also be automatic. You’re probably thinking of registered trademarks which are indeed not automatic. Both kinds are often illegal to infringe, but unregistered trademarks have fewer and weaker remedies in court.

Whenever you see the raised TM symbol, that’s claiming trademark status but not necessarily registered trademark status. The R in a circle is restricted to registered trademarks.

You can see here that Apache’s trademark for Spark is unregistered, but that doesn’t make it invalid (at least in the US and the other countries I alluded to): https://www.apache.org/foundation/marks/list/#unreg_s

Fun fact: it’s also possible to register trademarks with US states, but that’s almost always worse than doing so federally with the USPTO, and federal registration is valid nationwide. State-level trademark registration is mainly a historical artifact predating the federal trademark system, but it’s still technically available.

And the article refers to “spark applications”, which immediately brought to mind the Apache Spark.

GitHub Spark is not open source software, so there shouldn't be any confusion.

They could've called it GitHub Moist, or Github Fungus, or Github Bequeath. They didn't for a very simple reason:

The vocabulary isn't infinite. And within that finite number there's an even smaller set of words you would use for a product. And within that there's an even smaller set of words that are a combination of some of all of pleasant/short/applicable/relevant.

And Spark is a choice because the icon of choice for all things AI-related seems to be the sparkles emoji.

I'll point out that "github" and "microsoft" were not on any dictionary prior to their current use.

We (the GitHub Next team) use and love Apache Spark. So we made sure to connect with ASF before releasing GitHub Spark, and confirm they were comfortable with us using this name.

We felt like there was sufficient difference between the two products, that there wouldn’t be any confusion. Especially with the target audience that GitHub Spark ultimately intends to reach.

That said, we plan to validate this during the Technical Preview phase. Since we absolutely want to be respectful of Apache Spark, and its impact on software.

The GitHub Next team sounds more like a department than a team. It also sounded odd to hear that a group of that size uses and loves something that is unlikely to be used by a large percentage of the team directly. Yay corporate motivational speak! I can use another look at https://despair.com/collections/demotivators after this.

When GitHub Next asked for this, there was already pressure in place for ASF to give that to them, because they're locked into GitHub, so it may not have been given entirely freely. You can say that you're confident it was, but to me it seems impossible to know for sure. I don't know if it was or not. It might be that they would have decided to give it freely but the thought of their relationship with GitHub came to mind while they were considering it. In any case, it's a big ask, because if this takes off, soon the phrase Spark Application that another commenter mentioned will be ambiguous.

Out of curiosity: what size do you think constitutes a “team” vs. a “department”?

GitHub Next is 18 people (inclusive of all roles), which seems appropriately-sized to be called a “team” (certainly in a large engineering company).

But apologies if that came off as misleading.

With more than 10, I tend to prefer the term department, though the term department could also be used for an organizational division with a smaller number of people.

The way Cloudflare has Departments on their jobs page fits my mental model of it. One is Emerging Technology and Incubation which sounds similar to GitHub Next. https://www.cloudflare.com/careers/jobs/?department=Emerging...

On the GitHub jobs page, there isn't such a selection, but in autocomplete there are two results for team and none for department or group: https://www.github.careers/careers-home/jobs

"Experienced developers can still see and edit the code"

I'm curious about the quality of the generated code. Does it adhere to any principles? Is it readable to developers? Is it easily extensible?

I love the idea of a code generator for developers that can generate a scaffold from natural language, but I am dubious of an entire app which can be generated from natural language.

For many people describing an app is the challenge itself. That’s why we have digital product managers who use formal methods like user stories to describe the system or write specs and requirements documents for engineers.

There's no it way won't suck, so it's good to github built in a way to iterate and called it experimental. We need much better llms, or some other technique, before we can have anything like this.

People have been trying this building software in plain English bullshit for at least 65 years, look into the history of cobol. It didn't work last time, or the time before, or the 50 times before that. It absolutely will work someday, but there's no compelling reason to believe that day is coming in the next month or two.

>look into the history of cobol. It didn't work last time,

I believe that Cobol did work, in relatively narrow but important niches. It worked, but was hated.

Oh yeah Cobol absolutely worked as a programming language, but it never lived up to the promise of being a plain English replacement for code which was a common promise at the time.

Github Spark looks like v0.dev, and v0 is much faster than me in building a good UI in React. It also often creates better UIs than me. But after the basic interface is up, it’s better for me to connect it to the backend or add interactivity myself (with the help of inline copilot completions of course).

In the end, it does speed up my development of applications.

I think we don't really need better llm.

Biggest problem is the context window and understanding of context.

Those are features of the llm

of course, but to evaluate or train better LLM you need to have first some framework/application like gh spark working. just look at aider and how well it's able to estimate llm coding performance. like with everything in the past we need first to build something that is helpful for some cases and then improve it every generation.

I believe spark will be great for some internal tooling or some personal side projects, you don't have to handle every corner case in such application

This is going into the wrong direction. Instead of using plain English to describe programs, we should rather use programming languages to describe the rules of our society.

Because nowadays lawyers, judges and politicians are trying to write and interpret the rules for our society in plain English and the outcome is a mess. E.g. all those tax loopholes are in principle programming bugs, which should have been caught by (automated) tests, but doing this in plain english is just much too ambiguous.

I'm thinking a lot about these tools, and the biggest challenge in the space seems to be figuring out the right unit of work for AI to take on.

A signle class/function is too small to be that helpful, a whole app is too big and complex. A whole ticket is also still too big. What's inbetween? If you could divide projects into units of work of consistent complexity calibrated to AI's abilities, then you could probably get really good results.

I'm building something similar, with a focus on quality. There's a wait-list you can sign up for in the meantime: https://aiconstrux.com

The problem with ai is the error checking piece. It’s nice that it can do this but I don’t see evidence it can validate what it generates at scale. Even then, how would you validate an ai validation ?

You could audit the generated code.

I think this is missing the point. The whole point is for it to do things you don’t know how to do.

For instance , generate a web front end that meets U.S. rules and regulations for executing a 401k roll over.

If you didn’t know how to do this then how can you audit it?

By paying a software auditing company.

Measuring app usage and adoption could be a useful proxy.

Might be the "new Excel" as in bringing some light programming to non technical people, but hopefully only for internal tools and things I don't have to use.

https://news.ycombinator.com/item?id=41804291

We are building a similar thing for non technical users.

I wonder if this will completely replaces scripts, shortcuts and If this than that type of Apps.

AI might be nice to generate stuff. But as all code generators it has the issue of supporting the generated code long term.

With AI it is even worse: You don't get reproducible runs: Trying to fix a simple layout bug and suddenly some updated AI generates something completely different because it learned some new tricks and you cannot go back to what you had before and suddenly the whole page doesn't work anymore?

Sounds like fun!

Ya, even claude artifacts have replaced scripting for me to some extent. For example, if I need some data transformation thing "Create a web app that takes text input and does X, Y, and Z".

It's correct for me 99% of the time, and the remainder I can trivially ask it to tweak something. (especially since for those kind of one-off tools, I really don't care about the actual UI and styling)

Beats figuring out the right incantation of JQ, regex, whatever other tool I only use every 3 months, ... every time. And I can trivially just go back to that artifact and iterate on it later.

The dream of COBOL lives on...

Reply on news.ycombinator.com