Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
abreslav
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
by
abreslav
6mo ago
> * model transforms text into a formal specification formal specification is no different from code: it will have bugs :) There's no free lunch here: the informal-to-formal transition (be it words-to-code or words-to-formal-spe
2.
▲
by
abreslav
6mo ago
When you translate spec to tests (if those are traditional unit tests or any automated tests that call the rest of the code), that fixes the API of the code, i.e. the code gets designed implicitly in the test generation step. Is this workin
3.
▲
by
abreslav
6mo ago
Very much agree on coverage. We're actually doing something in that area: https://codespeak.dev/blog/coverage-20260302 For now, it's only about test coverage of the code, but the spec coverage is coming too.
4.
▲
by
abreslav
6mo ago
Very much agree. I like the imperative vs declarative angle you take here. Thank you!
5.
▲
by
abreslav
6mo ago
We'd love to hear your feedback! Feel free to come to our discord to ask questions/share experience: https://l.codespeak.dev/discord
6.
▲
by
abreslav
6mo ago
There are different kinds of tests: * regression tests – can be generated * conformance tests – often can be generated * acceptance tests – are another form of specification and should come from humans. Human intent can be expressed as * do
7.
▲
by
abreslav
6mo ago
Two things to mention here: 1. You are right that we can redefine what is code. If code is the central artefact that humans are dealing with to tell machines and other humans how the system works, then CodeSpeak specs will become code, and
8.
▲
by
abreslav
6mo ago
We are not trying to make things easier for LLMs. LLMs will be fine. CodeSpeak is built for humans, because we benefit from some structure, knowing how to express what we want, etc.
9.
▲
by
abreslav
6mo ago
> Also it seems that the tool severely limits the configurability of the agentic generation process, although that's just a limitation of the specific tool. Working on that as well. We need to be a lot more flexible and configurable
10.
▲
by
abreslav
6mo ago
> The limitation seems to be that you can't modify the code yourself if you want the spec to reflect it Eventually, we'll end up in a world where humans don't need to touch code, but we are not there yet. We are looking in
11.
▲
by
abreslav
6mo ago
I second that :)
12.
▲
by
abreslav
11y ago
Great slides! I hope we'll be able to adopt this style for our introductory materials
13.
▲
Kotlin's Java Interop: Top-Level Functions and Properties
(blog.jetbrains.com)
4 points
by
abreslav
11y ago
|
0 comments
14.
▲
Better Annotation Processing: Supporting Stubs in Kotlin's kapt
(blog.jetbrains.com)
11 points
by
abreslav
11y ago
|
0 comments
15.
▲
by
abreslav
13y ago
Many ideas of this sort are flying around, but we postpone the decision to some time after 1.0