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

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

breuleux.net

Post reply on HN
Print view View original

61–70 of 74 posts

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

#61

Post by berntb »

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…

In Perl 5 you can declare the version: use v5.16;

Then new features are turned on (and a few things change).

This of course implies that a new release have to support all old code, too. Painful to implement, but people expect and do get that 10-15 years old Perl code still work (unless dependent on other languages, of course :-) ).

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

#63

Post by mcnamaratw »

Well that's the problem that needs solving all right.

Yet again today I have a Python project that is already (at 200 lines!) obviously massively compressible if I had macros.

Maybe I can get there by returning functions & building up the functionality that way, but it feels like I'm trying to scratch that spot in the middle of my back, where I can't quite reach.

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

#64

Post by breuleux »

cle wrote: post #62

I'm curious, would it have been easier to change design decisions if you hadn't bootstrapped it?

Probably a little, but I don't think it would have made a big difference. It takes a certain amount of code before it becomes clear that the design has a flaw, and it's going to be the same amount of effort to adapt it, whether that code is in the compiler or elsewhere. A bootstrapped compiler just requires a bit more boilerplate in the transition.

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

#65

Post by [deleted] »

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…

[deleted]

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

#66

Post by candeira »

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…

Rich Hickey had about four lispy prototype languages before he set on the design on Clojure, it didn't spawn fully formed from his head. I think that's a sobering thought.

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

#67

Post by Tiksi »

labster wrote: post #58
MatthewMcDonald wrote: post #43

Earlier quoted context omitted.

This sounds pretty similar to the definition of a species. If two organisms of appropriate gender can't reproduce with each other, then they probably aren't the same species. If code from two samples can't be interspersed, then it's probably not the same language.

Under that definition, Perl and Python have finally merged, given Perl 6's Inline::Python. Peace at last! I'd probably go with a definition more like "mutual intelligibility" like for natural languages, but that doesn't seem right either. Sometimes I have to turn on the subtitles for British TV.

Yeah, under that definition everything that supports FFI has merged into a massive unholy mess with C. I guess if it can't be "natively" compiled/interpreted as the same language without inlining or including, I'd say it's a different language.

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

#68

Post by mcnamaratw »

mcnamaratw wrote: post #63

Well that's the problem that needs solving all right. Yet again today I have a Python project that is already (at 200 lines!) obviously massively compressible if I had macros. Maybe I can get there by returning functions & building up the functionality that way, but it feels like I'm trying to scratch that spot in the middle of my back, where I can't quite reach.

Rapid prototyping is this alternating process of building stuff up and then boiling it down. The building up is easier in Python, but the boiling down is easier in Lisp.

Sure would be nice to have both on tap.

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

#69

Post by raiph »

akkartik wrote: post #23
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…

I've been trying to break this catch-22 by experimenting with a language/VM/codebase without any backwards-compatibility guarantees. Instead of freezing interfaces for others to use, I'm going to guarantee instead that I'll have tests showing how to use my mechanisms, and you need to have tests for the programs you write using them. I'll try to make breakage happen in obvious rather than subtle ways, but if you don't…

The formal definition of a version of Perl 6 corresponds to (a frozen version of) the Perl 6 test suite (currently around 120K unit tests).

A compiler declares its claimed compliance by reference to these test suites:

  > perl6 -v
  This is Rakudo version 2016.01.1
  built on MoarVM version 2016.01
  implementing Perl 6.c.
6.c labels a frozen version of the Perl 6 test suite and thus a version of the Perl 6 language.

All serious users of the language are encouraged to check/improve the language test suite to ensure it covers what they want covered in either an existing version or an upcoming one.

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

#70

Post by raiph »

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…

> past a certain point it seems impossible to change a language in the ways that it needs to be changed to become good

I think it'll be a few years before Perl 6 matures enough for most folk to see why it matters, but its design incorporates Larry Wall's response to pg's http://www.paulgraham.com/hundred.html

Post reply on HN