“Screw it, I'll make my own” – The story of a new programming language • Hacker News Board

Re: “Screw it, I'll make my own” – The story of a new programming language

#71

Post by heimp » Sun, Feb 07, 2016, 9:02 PM UTC

xjay wrote: post #13

Curious. Are there examples of programming languages that allow spaces in identifiers? Obviously, it would need to be designed for that. I'm against the case-sensitive nature of some programming languages, and file systems for that matter. While it makes sense in a computing context (faster), you invent a new mode, just for the computer.. (Fortran was probably case-insensitive because upper-case letters were used fir…

I think Pogoscript, Argile and Zinc allow spaces.

http://pogoscript.org/guide/variables.html http://www.nongnu.org/argile/ http://tibleiz.net/zinc/identifiers.html

Re: “Screw it, I'll make my own” – The story of a new programming language

#72

Post by terminalcommand » Mon, Feb 08, 2016, 9:04 AM UTC

oldmanjay wrote: post #50

lisper wrote: post #3

Earlier quoted context omitted.

> I don't understand why people would use a dash "-" inside a symbol No need to use the shift key. At the levels of efficiency that a good language can reach, this matters. Also, dashes match established lexicographical conventions better than underscores because dashes look like hyphens.

I'm all for efficiency but based on my experience reading the code people write, the last thing we need is getting them to type faster. I'd prefer if some people slowed down a whole heck of a lot to think more about what it is they're doing.

I always thought autocomplete suggestions and snippets preserved brain cycles. IMHO if you prevent developer exhaustion your code gets better-looking and more maintainable. But then again I'm a single developer, working on personal projects...

Re: “Screw it, I'll make my own” – The story of a new programming language

#73

Post by merb » Mon, Feb 08, 2016, 8:46 PM UTC

akavel wrote: post #24

lmm wrote: post #18

> There is a bit of a catch-22 in language design where the more a language is used, the clearer it becomes which parts of it are problematic and should change, but the harder it gets to actually change them. To hone a language you must use it, but applications require that a language's features remain stable, robust, set in stone, and therefore as imperfect as they were at that moment. Furthermore, the more delays a…

A nice solution was used during development of the Go language: a tool for code rewriting (it was called "go fix"). It allowed the language authors to quickly and easily transform large swaths of code in the standard library, and also let everybody execute the same transformations in any third-party code. Thus enabling rapid and extremely painless iterations. [I'm consciously simplifying the story a bit to make it sh…

go fix didn't worked all the time. there were some edge cases where it failed. also syntax of go didn't changed much.

Re: “Screw it, I'll make my own” – The story of a new programming language

#74

Post by lmm » Wed, Feb 10, 2016, 10:38 AM UTC

breuleux wrote: post #44

akavel wrote: post #24

Earlier quoted context omitted.

A nice solution was used during development of the Go language: a tool for code rewriting (it was called "go fix"). It allowed the language authors to quickly and easily transform large swaths of code in the standard library, and also let everybody execute the same transformations in any third-party code. Thus enabling rapid and extremely painless iterations. [I'm consciously simplifying the story a bit to make it sh…

I think that's a neat idea. I've thought about it, but I've never used Go personally and I wasn't sure just how much it would help. I imagine it works best for languages with good static properties/tools for code analysis.

I think the important cases are the ones that you can't fix by hand - the ones where you're removing a dangerous idiom.