« first day (3094 days earlier)   

2:47 AM
@dzaima I linked to this in the programming language design Discord, but here's what I mean: docs.google.com/spreadsheets/d/…
 
 
4 hours later…
6:32 AM
@dzaima pretty amazing! Now I just need a fast python equivalent :)
 
6:47 AM
0
Q: Issues related to solving problem on optimal BST

ExcelsiorI was coding the problem https://www.codechef.com/problems/KOL16L I think I have solved it, but I ran into time limit exceeded issues. I am new in Competitive Programming, so I was seeking for a better, time efficient logic for solving the same. Time limit- 1 secs , My time -3.01 secs. Here is...

 
A__
7:25 AM
(This should be on-topic for golfing languages. I've came up with Ckoar, and it would be nice if anyone can implement it/give suggestions on improving golfing experience. It is an array-based language NOT influenced by APL.)
 
@A__ First of all, they're spelled "hieroglyphics" and "dyad".
What's your goal for this language?
 
A__
@lirtosiast I have created this language for code golf.
 
what specifically
as in, what is it supposed to do compared to other golflangs
 
If you're going for pure golfiness, it doesn't look very golfy compared to Jelly and Stax, for a multitude of reasons
 
A__
I want to minimize the variety of characters (to make programs easier to type in) as well for golfing purposes.
 
7:39 AM
minimizing character variety is pretty bad for golf
i mean i guess you could make a separate packed encoding
 
A__
@UnrelatedString If you have a Github account, you can make an issue/pull request; otherwise you can specify how Ckoar can be modified to be golfier.
 
If you want to make it easy to type you could just have an alternate ASCII syntax that transpiles into the single-byte code page based syntax.
 
A__
I am using the existing CP437 code page for all of the hieroglyphs, so it should be very easy to type in.
 
0) As currently described your syntax looks ambiguous. How does the parser know whether something is a nilad, monad, or dyad?
I won't comment on this further until you have an interpreter and we can see how parsing works.
 
A__
That is a problem in the description, and I don't know how to fix it. Maybe you can specify how they can be replaced (with the cost of increased character variety).
 
7:52 AM
You are the one who thought of making them all variadic
 
1) There's no way to have a competitive golfing language with 20 commands. You'll either need to use most of the 256 bytes in CP437 (like Jelly, 05A1BE, Actually, ...), or have at least 50 carefully written, heavily overloaded commands and write a "packed" representation (like Stax, which actually has >100).
Even with 100 commands you can fail to be competitive. Packed Pyth is generally no longer competitive, and Pyth took experienced golfer isaacg years to develop.
 
...oh, by the way, where might I find a link to this language design discord?
 
uh just search in the chat logs
 
oh so it's somewhere in here
sounds good
found it thanks
 
A__
@lirtosiast 0) I have came up with using parentheses when it is absolutely neccecary to avoid various interpretations.
0) Umm, otherwise the parser will be trying n-ads, dyads, monads, and nilads in this sequence.
 
8:03 AM
2) Your basic operations take way too many bytes. Storing subexpressions is one of the basic areas of a good golf language. Stack-based langs dedicate dozens of valuable characters on their codepage to stack-manipulation. Jelly has no variables, but four other ways to store and reuse expressions: $ and friends, μ and friends, the register, and calling links in multi line programs. You can't have your only command to store anything in any space but the current a 2 byte command.
 
A__
1) If variadic operations are used, then Ckoar should be very competitive in code-golf contests (if every command has a nilad, monad, and dyad form, there will be 768 different commands available. It is a relatively new language.)
@lirtosiast 2) Can you explain why basic operations take too many bytes when the user is preferred to use the CP437 encoding (where all characters are one byte long)?
 
3) So far this isn't an array-based lang as much as a lang with variables, some of whose names are numbers. Find a way to do something innovative with the theme.
@A__ To store something into a variable or into the array when you're already using the current array slot requires either ↨ or ↑, plus the index number or variable name respectively, which take at least 1 byte.
Btw how do I pronounce Ckoar? Is it shore with a k inserted?
 
A__
I randomly typed the name on my keyboard. You can pronounce it in any way you like.
Btw you can suggest to change the name if you think it is not appealing.
 
I have no problem with it
 
it's actually a nice name
 
8:12 AM
Anyway, what golflangs do you currently know? It's practically required to have familiarity with at least two golflangs with different paradigms before writing one.
Before being able to write a good one, that is
 
A__
I know Keg, based on the stack; and Doug, based on the Arch data structure. I am basing my language on Doug. Doug does even worse than Keg; however, it does better than Python.
 
if it's the same Doug as this one then it's not really going to help much with terseness to be familiar with
if you just want to make an interesting esolang without it really being competitive in golf then that's fine but it's not the same thing at all
 
Keg is barely a golfing language and Doug is definitely not a golflang and technically not even a language.
 
A__
I have tried GolfScript but I did not write programs in it anymore.
I undo my mention of Doug.
 
lack of any implementation aside, doug is not only deliberately verbose, but based on this "arch" data structure for the novelty of it, not because it's practical
 
8:23 AM
^
I would recommend to look at my spreadsheet of some popular modern competitive golflangs, select two with different paradigms, read through their docs, and post at least one nontrivial program in each.
 
Most of them have their own chatrooms where you can ask beginner questions.
Assuming you want to write a competitive golflang I'm not kidding about this. It took me 3 years of golfing in first (imperative) TI-BASIC, then (prefix) Pyth and (tacit) APL and Jelly, while also dabbling in some stack-based langs, before I was ready to start writing my own. And in not knowing Stax or Husk or Canvas or Brachylog, there's still a ton I'm missing.
 
As someone who knows Brachylog and has dabbled in Husk I don't think you're missing that much from there
 
A__
I don't know how people wrote the first golfing languages when there are no previous golfing languages available for reference.
 
@UnrelatedString I mean, some of the basic concepts are valuable
I plan to put declarative programming and currying in Sledgehammer after reading their docs. Maybe it's true that I wouldn't gain much from fluency.
 
8:41 AM
Yeah, Brachylog’s backtracking and constraint logic are quite useful even if the syntax can be awkward at times, and Husk… I guess its parser is pretty good sometimes, and it’s just overall nice to know
I’ve actually been thinking of making my language transpile to Prolog but I don’t want it to feel too much like Brachylog
Features aside Prolog is just a pleasant language to use, but then if I use it I have no good reason not to use the features
oh yeah and the currying
Husk's currying is great
Other paradigms have various features that accomplish essentially the same thing as partial application, but sometimes there's no substitute for the real thing
 
@A__ IIRC the first golflang was Golfscript. It sucked (e.g. abs was "abs", not even 1 byte). Once made Golfscript, we found there were significant improvements to be made, and so aditsu wrote CJam. isaacg wrote Pyth, and it became dominant due to its prefix syntax.
After this, the next improvement was Jelly, which Dennis probably came up with because he knew APL/J and CJam.
Since then all competitive languages have had syntax based on solid principles, with tons of builtins that are generally well thought out.
@UnrelatedString Do you know whether Brachylog could be golfier if it were prefix or postfix?
 
8:58 AM
I'm honestly not sure
I'm not really familiar with prefix-based golflangs though, except Husk I guess
You could have a golfier declarative language with a different syntax but I'm not sure how much you could look at it and say "that's sorta Brachylog"
A lot of code could end up looking quite similar in a postfix notation though.
 
Let's just say postfix then, you can always just flip it around
 
I also have zero experience with postfix but yeah
 
hm, other than being infix, what are the other inefficiencies with Brachylog?
 
Mostly just that it's infix
Except it's not really infix
There are some issues with how functionality gets allocated throughout the code page, like how every capital letter is a non-constraint variable, and superscripts and subscripts are separate from each other, but since we're still not even to the point of having written predicates for all of the lowercase non-dotted letters they're minor
And having a coherent aesthetic seems to be a high priority so those aren't really issues that would get addressed
 
oh, I wasn't aware the codepage wasn't full.
 
9:07 AM
Code page is full, just a lot of it isn't used yet
 
How is the evenness of character use? (I want to eventually run these numbers automatically but I'm having trouble getting non ASCII characters off the SE API)
 
As in which characters get used more than others?
 
Yeah
Maybe you remember, but Jelly had an issue with € being way too common, so some aliases were created and now it's significantly golfier.
 
Unused characters aside, there are probably some capital letters that almost never get written outside string literals because it doesn't really matter how we name our named variables, but that's not quite analogous to the problem (which I don't think I was here for since I only joined ~~PPCG~~ CG&CC five months ago), but I recall reading the issue on GitHub
The obvious analogue would probably be , which of course is map, just like
It may even be more overused than it was in Jelly since Brachylog just doesn't have vectorization
Also ; is big due to how much Brachylog relies on using lists to pass multiple arguments to predicates
One combination I find myself using a ton is ~c, and I find a subscript on it useful far more often than on non-reversed c.
I also feel like I'm ending up using ~c for things that might be best handled by some sort of metapredicate in the vein of ʰ/, but I'm not entirely sure how
Anyhow the biggest way in which Brachylog is not-quite-infix is that instead of having infix operators joining two values into an expression which evaluates to a third value, you have infix operators which take two variables and execute goals on them, and the relationships you declare between the variables are pretty much everything.
And one of the other issues is that although it uses CLP(FD) for integers, and integers in lists, it doesn't really offer the same experience for anything else, so it can be a pain to try to declaratively brute-force strings and lists in general and you end up having to handle them in more of a normal way, except it's not really built to do that
 
9:46 AM
Sometimes you just get a variable-not-sufficiently-instantiated error
 
 
6 hours later…
3:45 PM
@UnrelatedString still trying to get that VDM string or you want me to tell you?
 

« first day (3094 days earlier)