Timeline for How can we help users who are put off by the use of golfing languages?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 31, 2017 at 19:25 | comment | added | user58826 | +1 For the Java comment | |
| Nov 10, 2016 at 2:41 | comment | added | Esolanging Fruit | Honestly, I've been thinking about a language that's very verbose, maybe even more verbose than Java. The point is not to get the lowest byte-count, but to find potential for golfing. I feel like this would allow me to ignore the "best" solutions and think about how I, personally, would solve a problem. | |
| Sep 26, 2016 at 5:25 | comment | added | busukxuan | @Jordan Again, that's why I'm gonna make an assembler that does the exact same thing. Anyway that will have to wait, I don't even have time to spend on SE these few days. | |
| Sep 25, 2016 at 18:46 | comment | added | Jordan | @busukxuan If I built a golfing language I would give every operator a long, memorable (and tab-completable) name that could be mechanically replaced with its one-or-two-byte equivalent once the program is complete. It bewilders me (as someone who admittedly never attempted it) that most golfing languages aren't implemented like this. | |
| Sep 23, 2016 at 13:44 | comment | added | busukxuan | @mbomb007 That's why I was thinking about the assembler. I was thinking about indentation ect. that can clarify structure in addition to more memorable function names. | |
| Sep 23, 2016 at 13:41 | comment | added | mbomb007 | @busukxuan No, I think readability is a great concern. If other users can read it, then they can golf in it. | |
| Sep 23, 2016 at 4:37 | comment | added | busukxuan | @mbomb007 But IMHO golfing languages are more than just about how short the function names can be. Their range of built-in functions mean that there are more ways to achieve an end, wild being limited to one byte per semantic unit(except literals) means that the built-ins are limited in number so that they don't make almost every challenge become trivial like Mathematica does to most mathematically or scientifically related challenges. You also don't have to worry about the length of the functions' name, which is more about general-clever than programming-clever. What do you think? | |
| Sep 22, 2016 at 19:20 | comment | added | mbomb007 | @busukxuan The thing is, most of the languages like Pyth or whatever could be made more verbose and still have the same language structure. Suddenly any user could read it, and shortening your programs is still the same thought process. It just depends whether you're all about brevity, or if you value the golfing process more than the result. | |
| Sep 22, 2016 at 11:15 | comment | added | busukxuan | @Mego I actually think of that as a good thing for my brain, but indeed some people don't like that. Anyway there's a choice of paradigm. We have procedural, functional, array, and even logic paradigms. | |
| Sep 22, 2016 at 11:05 | comment | added | user45941 | @busukxuan I think part of the huge barrier to entry with golfing languages is the same as other esolangs - having to work with programming paradigms that you may not be used to with "traditional" languages. For example, a lot of golfing languages are stack-based. Having to get used to thinking in terms of a stack rather than variables/registers can be quite the hurdle. | |
| Sep 22, 2016 at 9:46 | comment | added | busukxuan | The "barrier" thing is half the reason I want to make a "golflang assembler". The other half is to ease golfers already using them. Now it seems I should start building it sooner. What do you think, would that help? | |
| Sep 22, 2016 at 4:30 | history | answered | Quill | CC BY-SA 3.0 |