My current pet project outside of work is developing a little programming language called Ein. I decided fairly early on in development that I didn...
For further actions, you may consider blocking this person and/or reporting abuse
Now, I rather like semicolons. I think they provide the punctuation needed. But then, I put in full stops (or periods, for our colonial friends), when I'm writing an SMS, let alone in text messages and so on, so maybe I'm the weird one.
I'm definitely not totally opposed to them - my favourite language by far is Rust, which does have semicolons!
I think for me it comes down to how they mesh with the overall feel of the language - languages like Rust have a lot going on syntax-wise, so the explicit syntax feels right, whereas Lua is quite minimalistic and 'light', for want of a better term.
I'd also say to a degree it just depends what mood I'm in, honestly :p
You missed a full stop at the end, there. twitches
I'm not trolling you, I swear! :D
(EDIT: Dev.to's formatting might be trolling me, though...)
I dont understand what you are talking about; Doesnt everyone write how I do; Then again I am not THAT popular;
F# does not have semicolons. I think it's different than the aforementioned categories, so you might want to check it out.
I like Lua. It's very tiny (about 100 KB footprint for the engine), and easy on the eyes. And is capable of doing large projects, like desktop applications.
For JavaScript, I like Standard as a formatter. Omits the superfluous semicolons.
I also like Python. No semicolons. (But it does have semantically meaningful indentation, which is my only twitch to the language.)
Line oriented programming languages, like Fortran or Basic, don't have semicolons. But they are line oriented. Which means you'd probably need some sort of "line continuation" marker.
I program in C++, which is a semicolon language. I also like D, which is another semicolon language.
I love F#, wish I got chance to use it more often :) Definitely my favorite functional programming language. Looking very briefly at the language spec, it seems like they do some sort of filtering on the the token stream to determine whether an operator is prefix or not? I was under the impression they just used the whitespace to figure that out, so that's super interesting - will have to investigate further :)
Yeah, the fact that Lua works well in a lot of different scenarios is one of the main things I like about it!
I think a good formatter is a must if you're going to use automatic semicolon insertion. This is probably why it's worked out quite well for Go - they bundle one with the language.
Python is a really cool language, and I love their attitude towards language design (Zen of Python, etc). That said, shakes fist in general direction of significant whitespace
D is a language I've heard a lot about, but never tried - need to check that out at some point!
There is also the solution of just adding an additional syntax to allow expressions as statments, a sort of a lexical cast.
You could just define your language as (concrete syntax):
or something along these lines.
Something along those lines is what I'm considering implementing in Ein, if the lack of expression statements causes issues :) Seems a lot nicer than having to create a temporary variable!
Personally i'm a beginner in programming, App developer for Android to be exact.
So in that case i coded using Java and C#, since i'm new to programming i'd rather have the semi colons so i'm not confused to the core wondering "what is what?",
i'd love to learn Lua though i find it very interesting! :D
There's definitely a lot of upsides to having stuff be explicit :)
Even as someone who doesn't write it that often, Lua is a super interesting language! Does a lot of things differently to other languages I've used.
I myself have just never quite understood not wanting semicolons. To me I'm always like "it's one extra key, and it's even apart of the home keys when typing. So easy to type." Plus it provides an even easier time for your brain to parse in my mind as you have a very good idea how the parser will read what you just wrote.
But I get it depends on the language. I've just never understood not wanting to use them. Even in languages where they are optional, I tend to use them. Of course this very well might just be because I was trained and groomed on the typical languages like C++, Java, and C# so it's just locked into my brain now.
interesting article.
another point of view on the 'statements vs expressions' issue is to get rid of all statements altogether and have everything be an expression.
this is the stance most often taken by functional languages and the one I prefer.
Overall, this is my preferred approach too! And it can work in imperative languages as well - Rust is my favourite example of this.
That said, I think it works a bit better in strongly typed languages than in dynamically typed languages - in the former case it's a lot easier for the compiler/interpreter to safeguard you from accidentally returning something when you didn't mean to.
JavaScript does not require semi colons either;
Google JS style guide explicitly requires them:
google.github.io/styleguide/jsguid...
Well I explicitly disagree with Google.
I explicitly disagree with JavaScript. Either you have semicolons or you don't.
I've seen this rise in popularity lately, and frankly I just find it harder to read.
There are many statements which often span multiple lines (looking at you promises...) and it's just more clear to me when there is a dedicated stop to the line. Might be because I come from a C background, but I always make linters require semi-colons.
Yep! They use automatic semicolon insertion, similar to Go.
Swift doesn't require semicolons either but you can add them if you want to put several statements on the same line.
I like Swift, it's a nice language.
Swift seems really cool! I'd like to check it out at some point, but they don't distribute Windows binaries, and I'm too lazy to compile from source... Eventually, though :p
Christopher Durham left a really interesting comment on my previous thread, explaining how Swift handles expressions-as-statements without creating syntax ambiguities. If I'm reading it right, they add a little bit of whitespace significance around operators to make it unambiguous whether they're infix, prefix or suffix. Another really clever solution to this problem :)