Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Ki Programming Language

github.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Show HN: Ki Programming Language

#71

Post by gavinhoward »

xigoi wrote: post #63
gavinhoward wrote: post #61

Earlier quoted context omitted.

Notes on paper are for humans. Programming languages are for humans and machines. Machines do better with braces. (I've written lexers for both.) Also, try to write an automatic formatter for a whitespace-delimited language; if your indentation is wrong, your logic is wrong, whereas with a brace language, if your indentation is wrong, you run a formatter, and it's all golden.

A parser is something you write once and then it's done, so it shouldn't be the deciding factor. And parsing indentation-based languages is not that hard, just replace indents and dedents with a special token. In a brace-based language, if your braces are wrong, your logic is wrong. How is that better? At least a mistake in indentation is much easier for a human to spot.

Run the formatter, and the brace-based mistake is easy to spot too.

Re: Show HN: Ki Programming Language

#73

Post by xigoi »

gavinhoward wrote: post #71
xigoi wrote: post #63

Earlier quoted context omitted.

A parser is something you write once and then it's done, so it shouldn't be the deciding factor. And parsing indentation-based languages is not that hard, just replace indents and dedents with a special token. In a brace-based language, if your braces are wrong, your logic is wrong. How is that better? At least a mistake in indentation is much easier for a human to spot.

Run the formatter, and the brace-based mistake is easy to spot too.

So what's the point of having braces if you're going to use indentation anyway?

Re: Show HN: Ki Programming Language

#74

Post by gavinhoward »

xigoi wrote: post #73
gavinhoward wrote: post #71

Earlier quoted context omitted.

Run the formatter, and the brace-based mistake is easy to spot too.

So what's the point of having braces if you're going to use indentation anyway?

To do more things with the source than just compile it.

Re: Show HN: Ki Programming Language

#76

Post by gavinhoward »

xigoi wrote: post #75
gavinhoward wrote: post #74

Earlier quoted context omitted.

To do more things with the source than just compile it.

And how do braces and semicolons help you with that?

Exactly what I mentioned above: source formatting is just one of the things you can do with braces and not significant whitespace. [1]

Also, forget a brace in your program, just one, and the compiler can tell.

Forget one indentation? No dice.

And while braces can break things too, editor settings can make it much easier to break things with significant whitespace. [2] [3]

Also, refactoring. [4]

Editor stuff. [5]

[1]: https://news.ycombinator.com/item?id=3296782

[2]: https://medium.com/@rwxrob/significant-whitespace-is-still-t...

[3]: https://news.ycombinator.com/item?id=24854090

[4]: https://lobste.rs/s/yyuo7f/significant_whitespace_good_bad#c...

[5]: https://lobste.rs/s/yyuo7f/significant_whitespace_good_bad#c...

Re: Show HN: Ki Programming Language

#77

Post by xigoi »

gavinhoward wrote: post #76
xigoi wrote: post #75

Earlier quoted context omitted.

And how do braces and semicolons help you with that?

Exactly what I mentioned above: source formatting is just one of the things you can do with braces and not significant whitespace. [1] Also, forget a brace in your program, just one, and the compiler can tell. Forget one indentation? No dice. And while braces can break things too, editor settings can make it much easier to break things with significant whitespace. [2] [3] Also, refactoring. [4] Editor stuff. [5] [1]:…

Python does have an auto-formatter [6], so clearly indentation doesn't prevent that.

> Also, forget a brace in your program, just one, and the compiler can tell.

Should we duplicate every character, so the compiler can tell if you leave one out? This is not a radiation-hardened quine [7].

> editor settings can make it much easier to break things with significant whitespace.

Then use an editor which doesn't.

> Selecting all code contained in a brace or a parents is so much easier (in vim the % movement) than if you have to walk lines.

I have a plugin for Neovim that adds indentation-based motions. The implementation is trivial.

[6] https://github.com/psf/black

[7] https://codegolf.stackexchange.com/questions/57257/radiation...

Re: Show HN: Ki Programming Language

#78

Post by Tozen »

phpnode wrote: post #34
bheadmaster wrote: post #17

Earlier quoted context omitted.

V-lang is vaporware, designed to get Patreon bux off of gullible enthusiasts. See this post [0] from 2019. Things don't seem to have got much better in recent years [1] [2] [3]. [0] https://xeiaso.net/blog/v-vaporware-2019-06-23 [1] https://news.ycombinator.com/item?id=20230351 [2] https://news.ycombinator.com/item?id=20229632 [3] https://news.ycombinator.com/item?id=31793554

I've got no particular interest in V, but the hate it gets from a certain group of people here is really perplexing and I don't think it's at all warranted from what I've seen.

I too found it perplexing, and agree it's the right thing to call it out. As you and hu3 noticed, the methodology and continually spamming the same old posts and websites when the language is mentioned is consistent. When looked at as a whole, it comes across as an continual effort by certain parties (and wherever or whenever possible), to bully others for having different preferences or paint a very misleading and negative picture about Vlang (V-lang) for their benefit or purposes.

It's odd how obvious slanderous remarks and insults directed at developers (like grifter), in addition to provably false statements (like vaporware) are being pushed about the project (like language is unusable), don't seem to get removed. Somehow, that gets left up. Not just here, but other threads too.

Yet, attempts to directly refute or at least push back on the barrage of misinformation about a clearly popular GitHub project get flagged, downvoted, or removed. Don't think that would at all be tolerated if such was done to other open source developers and languages, nor for as long (many years). It isn't right nor is it fair.

Re: Show HN: Ki Programming Language

#79

Post by ki_ »

Tozen wrote: post #69
ki_ wrote: post #19

Earlier quoted context omitted.

I think v-lang is faster than ki, rust, go. But their memory management isnt waterproof. Also, they have been in development for a really long time and there isnt much progress. They should have reached 1.0 by now, but they havent and i think it's because the language might have problems. oh and, v-lang does have GC. they use boehm gc.

> ...they have been in development for a really long time and there isnt much progress. > They should have reached 1.0 by now... These are strange statements. People having any familiarity with newer programming languages are likely to not know or be confused by where this is coming from. V is a relatively new language that came out in 2019 and is in beta. So comparatively speaking, V has progressed well at the least…

I thought v was older, hmm, ok. But still, all these languages should have reached 1.0 by now. Except for jai, because jblow has other things todo. Wasnt c created in 2 weeks?

Re: Show HN: Ki Programming Language

#80

Post by Tozen »

ki_ wrote: post #79
Tozen wrote: post #69

Earlier quoted context omitted.

> ...they have been in development for a really long time and there isnt much progress. > They should have reached 1.0 by now... These are strange statements. People having any familiarity with newer programming languages are likely to not know or be confused by where this is coming from. V is a relatively new language that came out in 2019 and is in beta. So comparatively speaking, V has progressed well at the least…

I thought v was older, hmm, ok. But still, all these languages should have reached 1.0 by now. Except for jai, because jblow has other things todo. Wasnt c created in 2 weeks?

> Wasnt c created in 2 weeks

No, because C was derived from B. B was created in 1969 and was much of the basis of what would become C, which is given the release date of 1972. So we can make the argument of at least around 3 years of development, of what would be named C, before reaching a stable or usable enough state.

Languages and goals were much simpler in the past. Stages of development like alpha, beta, or what was 1.0 get kind of mixed up. It's not as clear a process, as we have today.

> Except for jai, because jblow has other things todo

Surely the other language creators had/have other things going on too. One of the main differences, that was attempting to clarify in the previous post, is that certain programming languages have huge corporate backing, which affects their development time. C (AT&T), Go (Google), Rust (Mozilla), and Swift (Apple) have reached 1.0 or stability faster, because of who they have supporting and pushing them.

Independent and more grassroots projects can sometimes achieve 1.0 in comparable times. But, this seems related to how exceptionally talented the lead developers are, experienced (as created other languages before), goals of the project (simpler is often easier), popularity, or how many contributors and sponsors got involved.

Crystal, looks to have took around 7 years to reach 1.0 (though with Windows support issues). Julia, comes in at about 9 years. Nim, another notable project, appears to have took around 11 years. We might can expect things to go a bit faster now, than back then, but within reason. And referring to programming languages that are reasonably well known and used.

Post reply on HN