<p>Some languages, such as BASIC (<code>STRING$</code>), Perl (<code>$scalar</code>, <code>@array</code>, <code>%hash</code>, <code>&amp;sub</code>, <code>*symbol</code>), and others, use sigils affixed to variable names to indicate their types. Most other languages use either unadorned variable names or a single symbol to mark all variables.</p>
<p><strong>(How) do programmers act differently in these languages than others?</strong> For example, do they make productive use of same-named variables of different types, does the ability to know the data type immediately on sight have a positive impact on code comprehension or debugging, does tracking multiple significant symbols introduce more opportunities for error instead? I'm looking to find what value, positive or negative, this design element brings to the <em>user</em> of the language (rather than the implementor).</p>
<p>For this question I'm thinking only of cases where this is enforced at the language level, not Hungarian notation or other naming conventions, and these are sigils for data type, not scope or lifetime.</p>

<syntax><variables><language-ergonomics>
What impact do type sigils have on programmers?
CC BY-SA 4.0
2024-04-12T00:45:41.213Z
Interesting question; the next time I run into one of the original implementors of Visual Basic I'll ask what motivated making those optional and whether there was any customer research behind it.
Eric Lippert
CC BY-SA 4.0
2024-04-14T16:23:05.260Z
Would Fortran count here? It doesn't (didn't?) use sigils, but would instead use the first letter of a variable name to determine its type, unless explicit specified, leading to the joke "God is real, unless declared integer".
Matthieu M.
CC BY-SA 4.0
2024-04-14T21:46:59.160Z
Fortran doesn't seem like it covers any of the relevant points except "know type on sight", but it doesn't even have that, as you note. Unless there *is* a version with sigils it doesn't seem like it can be hugely relevant, but perhaps there's something in it.
Michael Homer
CC BY-SA 4.0
2024-05-15T03:40:25.023Z
I don't know if there are any "serious" languages with type sigils because you can only have as many types as you have sigils, which isn't a lot. I think Perl 4 (which I never used) had one type per sigil, but Perl 5 dumps `[]` lists and `{}` hashes and every custom type defined by every library into `$`, making the other Perl 4 types feel a bit vestigial. Also the sigils aren't really attached to the identifiers in Perl since `$foo[...]` indexes `@foo`, etc.
benrg
CC BY-SA 4.0
2024-05-15T03:56:09.593Z
"Scalar" as a type encompasses quite a lot, but it's not less of a type for it. The indexing syntax of Perl 5 was a bit odd and Perl 6/now Raku use `@foo` and `%foo` when indexing as well, so it indicates the container type rather than the value type. I think both of those choices are defensible, although what I'd like is answers about what the effect of either of them is.
Michael Homer
CC BY-SA 4.0
2024-06-18T22:17:35.837Z
@EricLippert: Didn't Visual Basic simply inherit its `string$`/`int%`/`long&`/`float!`/`double#`/`string$` convention from QBASIC, which inherited them from GW-BASIC?
dan04
CC BY-SA 4.0
2024-06-19T00:22:40.010Z
@dan04 In Visual Basic the `$` is optional - `A` and `A$` refer to the same variable, unlike in QBasic - so there was at least a choice made at some point. I have the VB 5.0 Programmer's Guide here right now, and it exclusively suggests Hungarian notation and `Dim ... As ...`, and doesn't use type-declaration characters anywhere. Finding out about how that decision was made would be great, especially if it turns out to have had some research behind it.
Michael Homer
CC BY-SA 4.0
2024-06-19T16:41:03.490Z
Yeah I checked my copy of the VB 3 language reference manual and, unsurprisingly, it does not have any background on why you'd choose to use or avoid suffixes that I could find. The documentation in that era was quite focused on what you could do and how, not what you should do and why.
Eric Lippert
CC BY-SA 4.0
2024-06-19T16:45:05.820Z
Though frankly I would be quite surprised if any part of the early VB design was based on scholarly research in human centered language design. When I was on the VB team as an intern in the middle 1990s the emphasis was on making specific tasks easier for programmers, particularly "opportunistic" programmers who came to programming as a way to improve processes in their actual profession. Finding places where the compiler "got in the way" and streamlining them was the motivation for a lot of work. It seems plausible that making sigils optional was motivated by that goal.
Eric Lippert
# What impact do type sigils have on programmers?
Posted by: username_0 on 2024-04-09
Some languages, such as BASIC (`STRING$`), Perl (`$scalar`, `@array`, `%hash`, `⊂`, `*symbol`), and others, use sigils affixed to variable names to indicate their types. Most other languages use either unadorned variable names or a single symbol to mark all variables.

**(How) do programmers act differently in these languages than others?** For example, do they make productive use of same-named variables of different types, does the ability to know the data type immediately on sight have a positive impact on code comprehension or debugging, does tracking multiple significant symbols introduce more opportunities for error instead? I'm looking to find what value, positive or negative, this design element brings to the *user* of the language (rather than the implementor).

For this question I'm thinking only of cases where this is enforced at the language level, not Hungarian notation or other naming conventions, and these are sigils for data type, not scope or lifetime.
**Tags:** syntax variables language-ergonomics
> **Comments:**
> **username_1**: Interesting question; the next time I run into one of the original implementors of Visual Basic I'll ask what motivated making those optional and whether there was any customer research behind it.  
> **username_2**: Would Fortran count here? It doesn't (didn't?) use sigils, but would instead use the first letter of a variable name to determine its type, unless explicit specified, leading to the joke "God is real, unless declared integer".  
> **username_0**: Fortran doesn't seem like it covers any of the relevant points except "know type on sight", but it doesn't even have that, as you note. Unless there *is* a version with sigils it doesn't seem like it can be hugely relevant, but perhaps there's something in it.  
> **username_3**: I don't know if there are any "serious" languages with type sigils because you can only have as many types as you have sigils, which isn't a lot. I think Perl 4 (which I never used) had one type per sigil, but Perl 5 dumps `[]` lists and `{}` hashes and every custom type defined by every library into `$`, making the other Perl 4 types feel a bit vestigial. Also the sigils aren't really attached to the identifiers in Perl since `$foo[...]` indexes `@foo`, etc.  
> **username_0**: "Scalar" as a type encompasses quite a lot, but it's not less of a type for it. The indexing syntax of Perl 5 was a bit odd and Perl 6/now Raku use `@foo` and `%foo` when indexing as well, so it indicates the container type rather than the value type. I think both of those choices are defensible, although what I'd like is answers about what the effect of either of them is.  
> **username_4**: @EricLippert: Didn't Visual Basic simply inherit its `string$`/`int%`/`long&`/`float!`/`double#`/`string$` convention from QBASIC, which inherited them from GW-BASIC?  
> **username_0**: @dan04 In Visual Basic the `$` is optional - `A` and `A$` refer to the same variable, unlike in QBasic - so there was at least a choice made at some point. I have the VB 5.0 Programmer's Guide here right now, and it exclusively suggests Hungarian notation and `Dim ... As ...`, and doesn't use type-declaration characters anywhere. Finding out about how that decision was made would be great, especially if it turns out to have had some research behind it.  
> **username_1**: Yeah I checked my copy of the VB 3 language reference manual and, unsurprisingly, it does not have any background on why you'd choose to use or avoid suffixes that I could find. The documentation in that era was quite focused on what you could do and how, not what you should do and why.  
> **username_1**: Though frankly I would be quite surprised if any part of the early VB design was based on scholarly research in human centered language design. When I was on the VB team as an intern in the middle 1990s the emphasis was on making specific tasks easier for programmers, particularly "opportunistic" programmers who came to programming as a way to improve processes in their actual profession. Finding places where the compiler "got in the way" and streamlining them was the motivation for a lot of work. It seems plausible that making sigils optional was motivated by that goal.  
---
## 0 answers
