Jeez, next you'll be telling us you don't like perl
What would the perfect programming language look like?
- Thread starter iljitsch
- Start date
Given that the semantics of
while and do while are fundamentally different (0 or more times vs at least once), no, that doesn't strike me as a good idea. Much the same can be said for for.
Edit: beaten
I used to have fun with code making all my C while loops use the
I used to have fun with code making all my C while loops use the
for statement. I think for and while are by far the most used and can turned into one another pretty easily. However, do... while is usually handled a little differently. It will execute the code block and then do the check so the code block is always executed at least once, even if the condition is false from the start so a do... while executes the code block 1+ times. That's not guaranteed with for or while, which check the condition before executing the code block which means the code block will be executed 0+ times. You can turn the do... while into the others but it requires messing with stuff.
Is that a fundamental difference?
I'm not saying this is the best syntax possible, but instead of a
while (condition) we could use for (; condition; ) and instead of a do... while (condition) we could use for (i = whatever_it_would_otherwise_have_been - 1; condition; i++).Also, I have almost never seen a
do... while loop that wouldn't have been clearer and easier to understand had it been a while instead. Maybe that's just me.perl is a write-only languageJeez, next you'll be telling us you don't like perl
That will work for index counting loops. What if your condition is the return value from a function? or a value read from a file? or the existence of a particular element in an XML DOM? or if you want to
do... while until you get an EOF from the file for some reason? It can certainly still be done but what you may have to do may be pretty ugly... especially if the condition is a function call that modifies state somewhere. I guess you could do something like:
Code:
bool doThisOnce = true;
while (doThisOnce || callThisFunc())
{
doThisOnce = false;
....
}But that
.... in there may be a little trickier.In addition to what @fitten said, we should be valuing readability and expressiveness. Realistically, the intent behind a
And, anyway, everyone knows that tail recursion is the right way to write a loop.
for loop and a while loop is theoretically different. There is a significant difference in meaning between for and while. One refers to a mathematical idea of iterating some collection or a list comprehension: "for each number between 1 and 10" while the other suggests waiting for some kind of external condition: "while it is raining". The idea that you can write the latter as "for it is raining" only obscures the difference between what is going on.And, anyway, everyone knows that tail recursion is the right way to write a loop.
Um, but that's pretty much the heart of any discussion of what a "perfect" language would be. Otherwise, everything just boils down to a Turing Machine as the one true form of computation!
Well, the abstract construct for them all is conditional execution of a block of code, so you might as well find a way to throw out
if as a special case of that as well. And, of course, that's all the ?: ternary operator is, too, so out it goes. And death to all case statements! 
. . . 
Are we really making programming easier when we force it to be less expressive?That said, I do have a preference to see my conditions before the code blocks it controls. Consequently, I pretty much never use
do-while loops, and hate when I find myself using a post-if when a language's syntax doesn't offer anything cleaner for simple conditions.About while {} and do {} while;
These are both special cases. What we see in the example that ShuggyCoUk (sp?) posted earlier:
needs to have something happen before the loop-ending condition and also something after that condition. As the normal while only supports the latter and the do while only the former, if you want to move away from the insanity of side effects inside a conditional, you end up with this more general system:
These are both special cases. What we see in the example that ShuggyCoUk (sp?) posted earlier:
Code:
while(var line = f.Readline() != null)
{
// do something with line
}needs to have something happen before the loop-ending condition and also something after that condition. As the normal while only supports the latter and the do while only the former, if you want to move away from the insanity of side effects inside a conditional, you end up with this more general system:
Code:
while (TRUE)
{
line = f.Readline();
if (line == NULL)
break;
// do something
}I know I've used
In the end, my use of
do ... while a long time ago, but I don't remember why. I'd consider it code smell now.In the end, my use of
for (;;) and while has dramatically decreased when iterator-consuming pattern (like foreach keyword and Linq methods) made it to the language I used back then.If you need to do something an unknown number of times but at least once, anything other than
do ... while gets more obscure.Like my example with an infinite loop and an
if ... break. That's the best way to do some stuff at least once but other stuff not. But if it's everything at least once then do ... while is the most appropiate.
And the reason for that is exactly what?
As I said: I prefer the more outspoken format, as this is easier to spot.
Code:
}
}
}
}Which one is the closing "costumer" bracket?
Code:
</street>
</address>
</customer>
</person>Seems obvious in this case?
Keep in mind: we're talking about language design, not IDE design/features, which helps you with the brackets. My litmus test is a plain text viewer w/o syntax highlighting. Is code easy to read in it?
Again I ask, why?
It’s literally saying “I wish to be hobbled, then design my systems within those constraints”
Why even allow an editor: use cat, or read and be done with it. Go back to punched cards etc. etc.
Yes I’m sure there are still some luckless people limited to those circumstances in the world, but I’m entirely uninterested in expending effort supporting them/enabling them.
The only reasonable “we should enable working in these constraints” I can get behind is making things work for people with visual/input/other disability problems. And that’s a very specific thing because AFAICT making the text amenable to very complex and clever tooling is in fact the way to go. I imagine a language designed for someone interacting with voice only would be very very different. Links to any research on that most welcome BTW.
Because sometimes, that's all you got.
Look no further then e.g. a [ code ] block in a forum like this.
I'm surely not gonna code in something like it. But reading and understanding source code outside of the IDE of my choice is something I do on a daily basis.
Because someone could easily type this by mistake:
Code:
} # street
} # customer
} # address
} # personAnd assuming the
# is a comment, there's no way to see that at least the comments are wrong, not that it would cause a compile-time or runtime error. And because comments are optional, no one would put them in The XML version can be caught very easily by the tools before you actually try to execute a program using it. At runtime, you will also get an error.Also, that while loop that opens a file and runs until EOF wouldn't normally be allowed in C#, for example, but they explicitly made an exception to allow that exact construct because it was so widely used.
If I'm doing serious code in there I type it into (say) LINQPad, then copy paste it in. Also means it compiles most of the time.
If I'm on a phone that's much harder, but then I try not to type too much there anyway if I cared I'd get something like this but many inline editors support syntax highlighting these days, including ars's (and indentation and bracket matching).
The bit I want to be able to read and understand outside an IDE is in diffs in github's UI and beyondcompare's (or the IDE of my choice). IME the braces and additional syntax often help there not hinder. If you have an immense monolithic xml/json/yaml file in source code then that's basically an antipattern and you should fix it. xml is notoriously unpleasant in git merges too so avoiding that is also good.
To be clear I'm not saying to go so far as using a non plain text format for code where you have to have sophisticated editors just to read the code (that makes things like diffs miserable anyway). I am arguing that making it required to be completely easy to use in all scenarios with an editor as dumb as notepad means other aspects most people spend more time in (and more time doing complex things) may suffer.
There is a trade off again which is why so many of us are repeating the "A perfect language" is impossible...
I wish @Metasyntactic was still here as he could cover this so much better than I could.
You want things like intellisense to work (for some value of work) even when the code it is parsing is broken. For that you need the entire engine to be capable of 'guessing' how too fill in gaps/tie a knot in "this bit is broken". The redundancies in the c# language verses (say) f# make that much simpler.
Roslyn (the c# compiler engine) does this by presenting the syntax tree and includes 'faked up' nodes in the tree (noting that they are missing) and largely does a great job of this because things like ';', '{', '}' and a whole bunch of other things exist to help know when to do this:
roslyn/src/Compilers/CSharp/Portable/Parser/LanguageParser.cs at 50e65d2653b8bfc07b271c8f813b6150becc378e · dotnet/roslyn
The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs. - dotnet/roslyn
github.com
See all the code around error recovery in the parsing: https://github.com/search?q=repo:dotnet/roslyn+error+recovery+&type=code&p=2 (there's a lot about it, sorry).
In f# the compiler engine (plus HM inference and partial application) can just keep on going for ages till it finally comes up with an irreconcilable problem (which IME pretty much only happens at the point indentation reduces (so screwing up indentation anywhere utterly screws you and the errors you get are entirely unhelpful
When using f# I trained myself to spot that a particular sort of error message indicated that I had fucked up indentation somewhere and needed to painstakingly walk the file by hand looking for the part that wasn't right, that's not fun.
There's an argument you don't need too much redundancy. For example that braces, semicolons and return indicators all together mean you can lose line terminators - I'm actually amenable to that one - but would definitely want actual hard numbers on how well/efficiently the compiler engine can recover in usual scenarios rather than just guessing.
Ease of parsing, generally. You must know that, or you would not be punctuating your sentences here.
Nope, because:
In a text editor, the text is just text. You have to bring in a validating XML parser to know that any of the verbosely formatted text is correctly representing the intended data structure. So, yes, the unadorned
{} isn't going to win any awards for clarity, but it's a mistake to think structural commenting is much of a win.Ugh. Give me
Markdown conventions any day of the week when it comes to readability of the text.Edit: Ha! I was today years old when I discovered Ars' editor handles Markdown formatting by default.
This all assumes the optimal situation that you and I sit at our well set up developer machine. Maybe my background in help desk and as a sysadmin is showing, but there were many times I had to look (or even fix) at configurations or scripts on a client's/user's machine that had nothing but Notepad (or Editor back in the MS-DOS days).
That's deeply wrong.
If you have to edit something locally and it's JSON then make your parser JSON5, but better is to use TOML or something else actually designed for humans.
Ease of parsing for whom? Men or machine?
For the latter: the newline character(s) is as good as a separator than any other for a machine. As for me: I don't need it. The opposite is true. As someone already explained above: it's easy to miss to add or remove a comma when editing JSON files.
I mean, if the "kiddie language" BASIC since forever did just fine without an explicit statement separator other then a new line, why are all those "serious adult languages" not capable of it?
And before someone jumps in ... yeah, I know, BASIC has ":" as a separator. But you use that if you want to write multiple separate statements on one line. For such a purpose, I obviously have no issues with a separator, may that be ":" or ";" or whatever.
Well, I have no choice what format a 3rd party vendor has it's stuff in. So I have to work with what I find.
Preferably both.
a newline in many languages without statement/exrpessions terminators is ambiguous (unless you require all newlines that are not terminating to have some form of escape character on thenm - are you advocating that it's not clear).
Ambiguity - even one that can be resolved as a human/compiler parses further gives less freedom for error recovery and allows some more subtle problems depending on other aspects of the language (see my gripes about partial application and f# above - this isn't sa made up concern, it bit me and others so so often)
Hence using JSON5 compatible parsers...
It's like saying markdown is crap for $reasons long since sorted by CommonMark, yes that's factually true but irrelevant to most people who got on board with a better tweak to the original.
The newline character is not a drop in replacement unless you add line extension escaping.
This is a facile, you know it and are better than it.
I am likely to start seriously coding in a language without semi colon separators full time shortly. IT will be interesting to see how that goes after f#. I might agree with you a lot more on this specific case, but even then that design decision will have been painstakingly factored into lots of other choices so it works as a whole, it's not a one size fits all.
Right. but that's just saying "a third party tool is shit". Yes it is likely true but since it's out of your control anyway using that to rail against languages/config formats that use commas at all (which is where some of this conversation started) isn't exactly very informative/driving the discussion
I think there's a significant disconnect in this discussion, with one side placing a lot of importance on things that to the other side are almost trivial syntactical details. The above is a good example of this.
The earlier works with relatively small code-bases, so weird issues like yours may consume relatively many resources compared to actually developing software.
The later works in large-scale software projects. When you work for, or run, software projects that are expected to consume person-decades or person-centuries of effort, you don't care about such situations at all. The cost of That One Problem WIth the Fucked Up Client is a rounding error for those projects. They're not really a problem you'd consider in a language selection; they're strictly a tooling/infrastructure/process problem, and are fixed like you would fix those problems.
Because treating it like this is what makes things scale.
For example to me the ability of a compiler to generate good error messages, even in a syntactically invalid program, is almost infinitely more important than the syntactical convenience of not having to type ';'. I care a lot about the former, because the compiler being able to emit (almost) all errors at once, even for source files with broken syntax, saves me a lot more money (and the developers a lot more work) than not having to type ';' ever would.
Ultimately at that level a programming language is a means to an end, namely having software that solves things you want to see solved, solved well, and preferably solved at acceptable costs. I know that this may sound unsatisfiying and ... almost boring and banal to some, but this is what a lot of language selection boils down to.
Last edited:
Exactly what ramases wrote, but to add further and explicitly.
The people doing the smaller stuff are just as valid and important and it's totally fine for tooling/languages to cater well to them. But this reinforces that there is no "one perfect language" because homogenous we are not - and that's a good thing
The people doing the smaller stuff are just as valid and important and it's totally fine for tooling/languages to cater well to them. But this reinforces that there is no "one perfect language" because homogenous we are not - and that's a good thing
Exactly what ramases wrote, but to add further and explicitly.
The people doing the smaller stuff are just as valid and important and it's totally fine for tooling/languages to cater well to them. But this reinforces that there is no "one perfect language" because homogenous we are not - and that's a good thing
Definitely this. At no point would I want to disrespect either the people that work on the smaller projects, or what those projects want to accomplish.
Language design is a series of trade-offs, which differ between small and large projects, and there's no one true answer.
I also think that what constraint a statement separator put on a compiled language are not the same than it put on a script or description language. It's the difference between failing at compile time and failing at run-time; between always been edited in IDE and may be edited in Notepad or nano.
But don't we all start in the first category?
Although we mainly write code as input to a computer (the compiler or interpreter), we also write code for other people to read. Obviously code must be human writable in some fashion, but it also must be human readable. And although we don't print as much as we used to, having code on paper is still a requirement in my book. (And I have my K&R lying next to my keyboard to underscore that point.)
I'd say that XML straddles the edge here. Sure, it's nice that whatever the software that groks XML is called can easily detect errors like closing the wrong tag, but XML is just a disaster to work with as a human without software to help you.
And life is definitely too short to start learning how to do that at my age. So obviously I had tons of fun writing code to generate Apple .keylayout files containing all kinds of weird Unicode characters.
Yeah, humans shouldn't be messing around with it as much... which is why that tools can be made to help a lot when you have to. And it's very good that tools can be made to do it and that it's so strict. Ambiguity isn't a good thing, IMO.
I worked on an export program once... exported data from one vendor's database into an XML standard so it could be imported into another vendor's product. Periodically, I'd send an XML file with the latest export to the guy managing the project so he could feel free to spot check, run some tests against the XSD, etc. but not really for him, just keeping him in the loop showing that progress was being made, etc. On more than one occasion, I'd get message from someone else saying how that guy was flipping his lid because he tried to print out the XML file so he could look at the whole file (he was an older guy). So these XML files I was sending, just out of consideration to 'keep him in the loop', were just on a few test bits of data (just portions of the database, not the whole thing) and were anywhere from 900MB to 3GB in size.
Last edited:
This is what
tramp-mode is for... Turns out that so long as there is an ssh connection, there is no need to have emacs installed on the computer where you are editing a file.And this is what tools like
pandoc are for. Turns out that it is fairly simple to turn Json, Yaml, Edn, or whatever into whatever. You can write this party vendor stuff in whatever you want to write it in.It depends on the language, but certainly for some C-alikes, once you get used to using one that doesn't need semicolons, going back to one that does and adding them feels very much like compiler hand-holding that shouldn't be (and arguably often isnt) necessary.
Typescript is a counter example, but that's more a criticism of TS then not using semicolons.
OK, let me summarize what I already wrote in various replies: I don't know when exactly the first BASIC dialect did away with the mandatory line numbers. The first one I used was MS' QBasic included with MS-DOS 5.0, released in 1991. So for more than three decades there are compilers/interpreters which didn't need a helping hand in determining the end of a statement. And talking about about meaningful/good error messages. Again BASIC tells you "End If or End Select or End Sub or End Function or Next expected" instead of "} expected". And as you can see, I don't mind the additional typing of a character. I type much more in BASIC. But the benefit is better readability and better error messages.
I also suggest (for a new language) to make the standard case as easy to use as possible. When it comes to lines of code, I'm willing to bet a good amount of money that regardless of which language a programmer uses, in the overwhelming part of the code base one line equals one statement. More than one statement on one line is the the special case. So let's introduce a special syntax for that one, a statement terminating character. Same goes for having one line of code spanning multiple lines in the document. Another special case for which there is a special syntax. In short: the compiler should use what humans do naturally as its default. And the human's need to should support the compiler's parsing should be restricted to special / more rare cases.
I mean, we live in the 21th century, the AI rise (hype?) is real but the compilers with which we program these algorithms act like it's still 1960 even the (relatively) new languages like Go or Rust?
Not to mention the fact that all these compilers that now require a mandatory end of statement character are perfectly fine without such a thing when it comes to code remarks. For these the EoL character(s) do the job just fine.
I guess at this point we have to agree to disagree, which is perfectly fine - we had an interesting and fruitful and civil discussion nonetheless. Which is a lot worth these days.
When I started programming, most of the interpreters and compilers I had available were beginner-friendly and would stop at the first syntax error. Fix that, then you run it again, it gets a little farther, then you get the second error. Again. Again. If you're writing something that prints out e.g. factorial(atoi(argv[1])) or "hello world", you'll fix all the errors pretty quickly and be able to check that little assignment off as done.
A few years later and I'm blasting out 800 lines in an afternoon before I type "make". I get several dozen errors, warnings, stylistic complaints, on and on. If I looked at the first error, fix, repeat, it could be a couple more hours.
So the pattern of dealing with this that I settled on was to fix the bugs in reverse order. That meant that the line numbers of the error messages from the last compile remained valid as I went up the file fixing things. I could actually do something inefficient like print out the error messages on paper then hop into an editor with line numbers on and fix everything in one session. On a good day I'd only need to go through a couple cycles of this and then it's off to the races fixing semantic errors.
If it's an unbalanced curly brace or missing #endif, yeah I'll still have to fix that and recompile, but just normal screwed up syntax or misspelled/undeclared identifiers can still be fixed linearly.
This is very old fashioned though.
- A modern IDE with incremental compilation allows for a very fast cycle of clicking on the first error message, fix it, press F5
- compiling a large project isn't a 25 minute wait like it was in the 80's. make -j 10 scales really well, although it presents a new problem that error messages from different files might be intermingled in the output.
Always fun writing PHP that includes Javascript so the Javascript error messages come with a meaningless line number...
Writing in C#, I often use the null coalesce operater:
X = something ?? throw new long_named_exception(long message);
And usually put a line break before the ??
How would that work with no line terminator? Maybe BASIC style
X=something _
?? throw clause
X = something ?? throw new long_named_exception(long message);
And usually put a line break before the ??
How would that work with no line terminator? Maybe BASIC style
X=something _
?? throw clause
Operators like + or ?? can't go at the beginning of a line unless the previous line didn't terminate, so the grammar knows that it needs to keep processing tokens for the previous line.
About the only time you run into problems with ambiguity and need a line continuing operator is with something like -.