The purpose of Null Tracking in general (of which Nullable Types are only one of many different forms), is to somehow regain a modicum of safety (and sanity) in languages that have null references.
If you have the chance to eliminate null references altogether, that is a much better solution since the problems that null references cause simply will not ...
Is it a bad design for a programming language to allow spaces in identifiers?
Slightly longer answer:
Design is the process of identifying and weighting conflicting solutions to complex problems, and making good compromises that meet the needs of stakeholders. There is no "bad design" or "good design" except in the context of the ...
The answer to your question:
Can every language be categorized as either compiled or interpreted?
Is "No", but not for the reason you think it is. The reason is not that there is a third missing category, the reason is that the categorization itself is nonsensical.
There is no such thing as a "compiled language" or an "interpreted language". Those terms ...
It depends on what you mean by "required".
Access modifiers are not a necessity. You could replace every access modifier with public and most applications will work just like they did when you used varied access modifiers, proving the point that the compiler's main goal (outputting a working application) is not directly dependent on access modifiers.
Embedding a language (I'll avoid characterizing it as "scripting") means that the following has been done:
The interpreter and runtime are running in the same process as the host application
Enough of the standard types and the standard library are also available from within that runtime
Most times, the application has its own library available to the host ...
No, it's not required: Bjarne Stroustrup, explained how he naively added protected to C++ release 1.2, thinking to provide a useful feature to class developers, just to conclude only 5 years later that it was a nasty source of bugs, that fortunately no one was forced to use. Nowadays, he recommends not to use it.
The practical arguments against ...
NULL is Overloaded.
NULL simultaneously means:
This variable has not been initialised
This variable has been initialised, but does not point to a valid object, and as such is invalid
This variable has been initialised, but does not point to a valid object, and this is perfectly valid
This variable has been cleared and should never be used again
This is the ...
The use of self can be traced back to Smalltalk, which is one of the eldest OO languages (the oldest according to python wiki) and influenced the python language designers:
There is evidence of a direct influence of Guido Van Rossum, since he was inspired for the early Python bytecode by the Smalltalk bytecode (see footnote 9 on page 26 of this article):
Much of the angst over nulls are due to languages where every reference type is nullable by default. But this is not an issue for Typescript or C# 8 so lets disregard that.
There are two basic approaches to how to optional values are represented:
A distinct container type (the Option type) which contain zero or one
instances of the actual value.
A union ...
One relatively well-known example is of some Fortran code in which a single typo completely changed the meaning of the code.
It was intended to repeat a section of code 100 times (with I as the loop counter):
DO 10 I = 1,100
However, the comma was mistyped as a dot:
DO 10 I = 1.100
Because Fortran allows spaces in identifiers (and because it ...
I think it is pretty obvious why in C# and Java - different from C++ - the designers choose to have access modifiers for each member. In C++, access modifiers are used in the header file of a class exclusively, where they are applied to member signatures which require seldom more than one or two lines, so grouping them in sections of public, protected and ...
If we are being pedantic, there is no such thing as a compiled or interpreted language, since any language could be in principle be implemented either by a compiler or an interpreter. However, most languages follow a relatively consistent implementation strategy. C++ is almost always compiled to native code. Python is almost always run via a bytecode ...
Let's take a look at two of the relevant functions:
template <class InputIt, class T>
InputIt find(InputIt first, InputIt last, const T& value);
template <class InputIt, class UnaryPredicate>
InputIt find_if(InputIt first, InputIt last, UnaryPredicate p);
Observe that both have an iterator-range first, and return an iterator into it (not ...
In his book "The design and the evolution of C++", Bjarne Stroustrup explains it himself:
The very first version of the language was called "C with classes". Stroustrup's intent was to introduce Simula-like classes into C (October 1979). (page 27 of the book)
From the start he wanted public/private access control and derived classes (no virtual ...
The main factor is typically the API that's used by host applications to access the language libraries. Languages like Lua are designed to be easily 'connected to' from host applications. The language may be available in library form, the API easily callable from other languages (generally a plain C API). The API usually provides functions to run a script,...
In theory any language can be embedded. If there are no constraints on the solution, it is actually the case. It's natural consequence of Turing completeness i.e. you can always build an emulator.
What I think you are asking is "what makes a language practical for this purpose?" I think one of the main things that makes a language a good choice for this ...
Before we decide that the protected access modifier must be removed from all popular OO languages I would like to point out that it would be pretty inconvenient to lose it.
In abstract base classes that serve as a blueprint for a number of derived classes you will likely have a lot of support methods for these derivatives that will be meaningless to the end ...
Python is also a language that strongly adheres to the object oriented programming approach. It uses the classical approach of classes and objects.
The thing to remember however is that any "word" is just a contract between you and (future) maintainers. Having a different, or even non explicit name for something does not mean that this contract is not there....
Pass me a null and I have to check for null to avoid throwing an exception.
Pass me an option, or an empty collection, or a null object, and I can avoid needing the check. I can use it the same as the other valid values and watch it quietly do nothing.
Use this wisely and it makes code easier to read.
Insist on checking for null and checks clutter code ...
Nullable types need 3 states in order to be safe and useful:
Unknown if it is null or not.
Definitely not null. Safe to assign to a non-nullable.
You can only encode two of those states at runtime in a memory pointer. The third state is determined statically at compile time. The compiler determines from the context that you have done a null check, so ...
Is it a bad design for a programming language to allow spaces in identifiers?
You forgot important implementation details:
what is source code for you?
I like the FSF definition of it: the preferred form on which developers work. It is a social definition, not a technical one.
In some languages and their 1980s implementation (think of original SmallTalk ...
A for loop is quite an important part of a programming language
No? For-each loops are arguably an important part of a programming language, but traditional for loops are a smell in everything but the most foundational code.
so you don't want to spend a lot of time typing it out every time for prototyping.
Typing code is a minuscule part of software ...
AFAIK, Option type will have runtime overhead, while nullable types won't, because Option time is an enum (consuming memory).
This is incorrect. Nullables have exactly the same overhead as option types in Rust, and overall the overhead can go either way depending on the language design. You can have option types with no overhead over nullables, and you can ...
Many functional languages have simple solutions for describing function types. The most common is a syntax rougly like the following, which is used to describe the type of any expression:
expr: a where a is the type of the expression. If the expression has a type that is a function, it will be:
expr: a -> b where a is the parameter type and b is the ...
Of course this only works if the re-inserted await is both idempotent (…) and side-effect free (so reordering the await statements should not affect the correctness of the program).
But await is used precisely in order to enforce a particular ordering. Await lets you enforce that an async operation has happened before you continue with other stuff. In many ...
It is not inherently bad design to allow spaces in symbol names. This can be shown with a simple counter-example.
Kotlin allows spaces in names. It also has official coding conventions which state when it is ok to use this feature:
Names for test methods
In tests (and only in tests), it's acceptable to use method names with
spaces enclosed in ...
There are multiple different ways to approach this answer (bold emphasis mine):
What is the reason python uses range in for loops?
This is not a for loop. It is a foreach loop. I.e. it is not a loop that loops over a pre-defined set of loop indices, it is an iterator that iterates over the elements of a collection.
In particular, in
for e in [2, 3, 5, ...
Note that range() is not actually part of the python language; it is a function. Having range be a function means you can plug any other function into a "for in" loop, including functions that don't increase monotonically, functions that lazy-execute, and functions that replace range() with something that better satisfies your personal sensibilities.
There are a couple factors:
whether the language has support for embedding API. Some scripting languages like Python and Lua has officially supported APIs specifically designed to embed those languages into a host application. This includes specifying how the language interacts with foreign function interface, foreign object handles, foreign classes, etc ...