Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!lnews.iecc.com!nerds-end From: Chris Newsgroups: comp.compilers Subject: Re: New Programming Language: Salmon Date: Thu, 3 Nov 2011 14:11:59 -0700 (PDT) Organization: Compilers Central Lines: 105 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-11-021@comp.compilers> References: <11-11-016@comp.compilers> <11-11-020@comp.compilers> NNTP-Posting-Host: lnews.iecc.com X-Trace: gal.iecc.com 1320357083 9272 64.57.183.34 (3 Nov 2011 21:51:23 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Thu, 3 Nov 2011 21:51:23 +0000 (UTC) Keywords: design Posted-Date: 03 Nov 2011 17:51:22 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:323 On Nov 2, 9:37 pm, Kaz Kylheku wrote: > On 2011-11-02, Chris wrote: > > > I've created a new general purpose programming language and a full > > interpreter for it. I'm looking for early adopters to give it a try > > and give feedback. > > I had a good look at your reference manual, etc. > > My honest opinion is that you've created a fairly uninteresting 'blub' > language, with new syntax and terminology for doing pretty ordinary things. I really appreciate that you took the time to do that, and that you gave your honest opinion, even if it was that Salmon wasn't very interesting to you. > For instance: > > quarks: objects that enumerate and identify, such that two quarks are > either equal or unequal. New term for "symbol", with limitations. > > tagalongs: your new term for "property lists" that can be attached to objects, > easily created with a couple of macros in Lisp and either weak hash tables > or finalizations (non-ANSI, but common extensions) to build the assocation > in a way that doesn't prevent garbage collection of unused objects. > In about 15 minutes of coding, I can make myself the syntax which supports > the following: ... I think to some extent this comes down to the whole question of why put any constructs at all in programming language, beyond a small core. As long as you have a certain minimal expressiveness in a language, any constructs you could add to the language could be emulated on top of the small core sub-set of constructs. There is a sizeable camp that loves lisp and sees it as preferable in nearly all cases to build everything on a very small core of basic language constructs. Whether adding constructs is useful or not is really subjective. It has a lot to do with how an individual programmer likes to think of things and how the proposed construct maps to the way the programmer thinks. Putting constructs in the language itself can give the advantages of syntax that can make it easier to read and compiler or interpreter support for checking the constructs are used as intended and for efficiently implementing them. It can also greatly aid readability by providing a basic set of concepts that all readers of the code in a language will be familiar with, and whose semantics they understand. About tagalongs in particular, there are some ways that tagalongs work in Salmon that are different than what you would get with your implementation. In your implementation, all values that are equal would have the same tagalong field for a given tagalong key, but in Salmon that need not be the case. For example, in Salmon I could have a function that returns the value 5 with a tagalong attached with additional information that would be visible to those with the proper key. On another call, it might also return 5 but with a different field value for that same tagalong key, to convey additional information that is different for that call. In your system, for a particular tagalong key, 5 would always map to a single field value at any given time. Also, in Salmon you cannot iterate over all the tagalong key/value pairs for a given object. This is deliberate. It's information hiding in support of modularity. Modules that don't have access to a particular tagalong key will never see it and never be able to tell it's there. This is a specific instance of the trade-off between introspection and information hiding to support modularity. > You've bogged down tagalongs with the possiblity of static type > declarations, which don't really add much value; they are just ways > to make the language get in your way. Whether adding type information to declarations adds value or gets in the way seems to be a subjective point on which many people strongly disagree. To me, adding type information is very helpful. It helps me record some of my reasoning in an explicit and unambiguous way. It helps me reason about the code later by knowing there are limitations on what values will be where when. It helps me find bugs more quickly because the language implementation will not let the type constraints be violated, and will tell me if something would violate them. > > I believe there's always room for new ideas, > > Why don't you introduce Salmon on Rosetta Code and try implementing > a few of the tasks, so people can get some rough idea for how it stacks up > against numerous other languages? > > In Rosetta, on the same page, people can see how a given task is solved in > Python, Lisp, SNOBOL 4 (!), Visual Basic, Salmon, C++, you name it. I think that's a very good idea. Thanks for the suggestion. I do think that it's hard to show off all of Salmon's strengths with code that does small tasks, though. I think one of the strengths of Salmon is supporting both programming-in-the-small sorts of small programs with a minimum of overhead but also supporting large, multi- developer projects, where type information and modularity support become very important. Unfortunately, it's hard to show off things that matter most only for really large, complex software systems. Again, thanks for the feedback. --Chris