I'm not saying that you shouldn't have semantics in mind, but no, I disagree with designing syntax last as much as I would with designing syntax first.

The syntactical decisions you make influence how you think about a problem as much as the semantic choices you make, and it needs to be a back and forth.

E.g. lisps homoiconicity fundamentally alter the freedom you have with respect to syntactic sugar (though I'd argue that it makes less difference than some want to think). If you leave the syntax considerations to the end, you will have potentially made semantic choices that constrain your syntax in ways you don't want.

This also applies in reverse.

You can't divorse the two.

The semantic concepts that made it into Ruby largely already existed, sure, but not the mix of them, and that mix is strongly affected by the syntax.

One effect of this interplay which I find a bit annoying (though I've looked long and hard for a solution that wouldn't be a grammar-nightmare), for example, is that while Smalltalk can (re)define core language features in a transparent way, Ruby can't, because while Ruby-style blocks can be very unintrusive, they are not invisible, so you can't simulate something like "if" or "while" without creating syntactic "noise".

These are conscious tradeoffs in Ruby - the cleanness of the core syntax was seen as more critical than retaining those features from Smalltalk. If the semantics had been designed first and dictated those features, then the current Ruby syntax wouldn't have been possible. We'd have gained some marginal utility, but we'd have lost readability.

OK: let's go with: design syntax any damn time you feel like it. Design it first and put finishing touches on it last. Design it while brushing your teeth or going to work, etc.

Don't give up too easily on Lisp. It also has picked up various syntax which has leveraged people's abilities.

As an exmaple, the backquote notation. Without it, it would be very painful to write macros at just one level of expansion. There is tremendous value in being able to do `(a b c (,@foo)) and so on, and it is a character syntax, like infix.

The possibilities for adding notations to Lisp without disturbing its syntax are not exhausted.

In my own Lisp dialect, I have introduced a modicum of notations which make quite a difference:

   obj.slot.a.b.c   ->   (qref obj slot a b c)

   obj.bar.(method arg)  -> (qref obj bar (method arg))

   a..b  ->   (rcons a b)   ;; construct range object

   [seq from..to]  ;; slice

   (fun arg . rest)   ;; dot notation with atom serves as apply

   (. blah)  -> blah  ;; dot not preceded by anything reduces to atom

   #"word list literal" -> ("word" "list" "literal")

   `quasi @literal @{blah[3]}`

All such little things make the "little code" you write daily a lot nicer.

It's understandable that coders might be put off by verbiage like (concatenate 'string ...) or (slot-value obj 'slot) or (aref array index).

> Don't give up too easily on Lisp

You assume I gave up on it easily. I didn't. I simply found nothing important enough to keep suffer the syntax. Not because there's nothing of value in Lisp, but because most things of value have been copied by many other languages by now. I'm not saying that Lisp doesn't have value any more, but that what it provides that other languages doesn't is not sufficient to outweigh the inconvenience of the syntax to me.

> The possibilities for adding notations to Lisp without disturbing its syntax are not exhausted.

The problem with this is that while you can do it for yourself, until/unless it gains traction you still need to deal with the surrounding ecosystem too.

Furthermore, the semantics of Ruby are not unusual at all.

Being a scripting language in a class with Python and many others, Ruby basically competes on syntax and libraries/ecosystem. As long as the ecosystem is good enough, it's reasonable to choose Ruby over, say, Python for developing web apps purely because you like the syntax.

What I'm getting at is how people will avoid Scheme, Prolog, Haskell, etc. because of "syntax". Which is a loss, and a bit ridiculous as sufficiently different semantics require different, unfamiliar, "scary" syntax. Getting over that is syntax prejudice is just a matter of adjustment.

> Furthermore, the semantics of Ruby are not unusual at all.

Depends on what you consider "unusual". It's not unusual if you're used to Smalltalk, Self or Lisp, with Smalltalk being it's largest semantic influence. Given how niche they are, there are plenty of areas that are "unusual" to a lot of people.

> Which is a loss, and a bit ridiculous as sufficiently different semantics require different, unfamiliar, "scary" syntax.

Except they usually don't. There are aspects of this with the Lisp family, where homoiconicity is important, that makes different syntax harder, but even there s-expressions was not the originally intended syntax, and "modern" variations show that there is room for other variants even with that property.

Heck, my Ruby compiler uses s-expressions as an internal representation (that you can "escape into" from source - it's used to implement low level details).

EDIT: You keep falling in two traps: One is to assume that rejecting a language means rejecting the lessons in semantics it brings. Ruby is proof that this is not true - it's a collage of ideas taken from other languages, and predominantly from Smalltalk, another language where syntax is one of the things people balk at. And it contains plenty of lessons from languages that went before - e.g. it has lambdas, it has continuations. It even has call/cc. It's not perfect - that's not the point at all - but it demonstrates that you can "lift" these ideas from other languages and package them in another syntax just fine.

The other trap is to assume that because syntax is unimportant to you, it's unimportant to others, and we just can't be bothered.

This is like being deaf and jumping to the conclusion that just because you do fine without hearing, everyone else should just ignore the extra signals they get from sound.

To me the use of syntax signals intent, and give hints about semantics (when well done) and outline the model of a piece of code. It provides extra information that is lost if the syntax doesn't let me express it. To sacrifice would be like losing my hearing: I'd still be able to function, but why in the world would I willingly give that up?

If there was something that offered sufficiently compelling semantics advances, I might. This is one of the reasons I've spent thousands of hours learning additional languages. But here's the thing: Of all the several dozens languages I've spent time on, very few have been all that different when it comes down to it, and especially modern languages are increasingly borrowing most of the important semantic concepts. Most of the semantic concepts that have been "left behind" have been left behind for a reason (consider INTERCAL's wonderful "COME FROM"; an early example of support for aspect-oriented programming)

This leaves syntax as a much more important differentiator for most than you might think. You've written off Ruby as "not that unusual" on the basis of syntax, while e.g. not considering that Ruby's main lineage are niche languaes like Smalltalk. That Ruby doesn't seem all that unusual is a testament to syntax.

E.g. a concept like being able to execute code in a class definition (not just being able - even "def" is conceptually just syntactic sugar; you can write Ruby code using just the method call define_method instead) is something that seriously messes with peoples mind. That 'require' in most peoples code is not a keyword but a method call that has in most cases been overridden by either rubygems or bundler is something most people aren't even aware of.

It's not that these concepts are "unusual" in the sense that they're not there in other well known languages. Ruby certainly isn't another Befunge or False or Aardappel [1]. These concepts certainly are present elsewhere - this is part of Ruby's Smalltalk heritage. But they're not what most developers are used to. Ruby has brought those concepts into the mainstream in a way languages like Smalltalk never managed. That Ruby is not "unusual" is a feature, not a bug.

[1] http://strlen.com/aardappel-language

You fell into a trap yourself! Did I say somewhere that syntax is unimportant to me? I am as particular about syntax as anyone you are likely to find.

What I actually am saying is that missing out on the good things a language has to offer because of an inability to get over your dislike of the syntax is a weakness. If you have no taste, there is nothing to get over. That's not what I'm saying.

Yes, yes, I know how you "suffer". That's something you can get over.

I don't know your goals--if you program only to satisfy your own creative urges then it doesn't matter how you choose a language.

Assuming you work on things that other people also work on, then there is a cost to rejecting a language only because of syntax.

For example, if you are doing some work in an area where everyone is using Python numeric libraries, and you refuse to use Python because of fussiness about syntax, then you can't collaborate with those people. There's no good reason for that.

Reasonable people should be able to see when certain choices are arbitrary, and get over their attachment to arbitrary choices when it gets in the way of more important things, like collaboration.

Failure to do what I just described is endemic among programmers, to our shame.