Due to a wave of criticism to use Global Vars in my Java post, I want to use a language without global vars. One suggestion per answer, thank you.
If you want to avoid side-effects you can use one of the pure functional programming languages like haskell (or erlang or ...), which have only constants. But be prepared for a completely different kind of programming compared to the imperative programming style.
I'm not sure if you literally mean no global variables (values that change), or if you also want to rule out global constants (values that don't change). Haskell is one such language that doesn't have global variables, although it does have global constants (in the form of parameterless functions, essentially). In Haskell, if you want to emulate global state, you have to pass your "global" variables into each function you call. A better description is available from the HaskellWiki.
If you don't want global variables then don't use them. I'm don't see why finding a language that doesn't support them would offer any value. You're dealing with a question of scope. Make your variables exist in the lowest scope possible and you'll be fine. There is no language that doesn't have a global scope.
Java (and similar OOP-languages) doesn't have really global variables, all variables are tied to an instance or a class. But I think you want also outrule the 'simulated' global variables (public fields with the only reason to be accessed from the outside). I don't think any of the popular languages don't allow this, but more uncommon language-concepts may have ways to avoid such things.
Well, I read that Graal is a functional programming language without variables, so I guess that might qualify.
I believe Eiffel doesn't use global variables but that isn't a serious criterion
of whether to use a language or not.
Newspeak has no global namespace and so no global variables, everything is late bound, I think other langages in the BETA family have the same property.
https://en.wikipedia.org/wiki/Newspeak_(programming_language)
The latest one entering this club would be V.
Related
In the natural number game, the use keyword resolves goals which contain existential quantifiers by assigning a concrete value to the quantified variable. Using Lean by itself it looks like use isn't available; what do you do instead?
You can use existsi, but in general the recommendation is to avoid using Lean by itself; mathlib should always be used as well. Set up your project as documented here then write import tactic at the top of your .lean file to get access to the use tactic.
Is there a list of items on the web that you should not use when creating a model or variable?
For example, if I wanted to create apartment listings, naming a model something like Property would be problematic in the future and also confusing since property is a built-in Python function.
I did try Googling this, but couldn't come up with anything.
Thanks!
Rules and constraints about naming depend on the programming language. How an identifier/name is bound depends on the language semantics and its scoping rules: an identifer/name will be bound to different element depending on the scope. Scoping is usally lexical (i.e. static) but some language have dynamic scoping (some variant of lisp).
If names are different, there is no confusion in scoping. If identifiers/names are reused accrossed scopes, an identifier/name might mask another one. This is referred as Shadowing. This is a source of confusion.
Certain reserved names (i.e. keywords) have special meaning. Such keyword can simply be forbidden as names of other elements, or not.
For instance, in Smallatalk self is a keyword. It is still possible to declare a temporary variable self, though. In the scope where the temporary variable is visible, self resolves to the temporary variable, not the usual self that is receiver of the message.
Of course, shadowing can happen between regular names.
Scoping rules take types into consideration as well, and inheritance might introduce shadows.
Another source of confusion related to binding is Method Overloading. In statically typed languages, which method is executed depends on the static types at the call site. In certain cases, overloading makes it confusing to know which method is selected. Both Shadowing and Overloading should avoided to avoid confusions.
If your goal is to translate Python to Javascript, and vice versa, I guess you need to check the scoping rules and keywords of both languages to make sure your translation is not only syntactically correct, but also semantically correct.
Generally, programming languages have 'reserved words' or 'keywords' that you're either not able to use or in some cases are but should stay away from. For Python, you can find that list here.
Most words in most natural languages can have different meanings, according to the context. That's why we use specifiers to make the meaning of a word clear. If in any case you think that some particular identifier may be confusing, you can just add a specifier to make it clear. For example ObjectProperty has probably nothing to do with real estate, even in an application that deals with real estate.
The case you present is no different than using generic identifiers with no attached context. For example a variable named limit or length may have completely different meanings in different programs. Just use identifiers that make sense and document their meaning extensively. Being consistent within your own code base would also be preferable. Do not complicate your life with banned term lists that will never be complete and will only make programming more difficult.
The obvious exceptions are words reserved by your programming language of choice - but then again no decent compiler would allow you to use them anyway...
I'm wondering if anyone if aware of a language that has support for variables (that could be considered 'global'), and subroutines (functions), but without a concept of parameter passing, local scope, etc. Something where every subroutine has access to every global variable, and only global variables.
BASIC and assembly come immediately to mind.
Of course, this is not construed as a feature. That's why we invent conventions for which global variables should be used for parameter passing.
As the title suggests I am wondering what the relationship between these two programming concepts are. Does a certain type system (static / dynamic) lend itself to a certain type of scoping (lexical / dynamic), or are these independent language choices?
Static typing doesn't work all that well with dynamic scoping since the variable binding is resolved at runtime. It's possible but it would be unwieldy, since the type system would have to type free variables somehow, probably by examining bound ones. Basically, you couldn't declare two different variables of the same name but different type. Strong and weak typing will also come into play. I'm still pondering what form a static, weakly typed, dynamically scoped language might take, assuming it's possible.
Lexical scoping is paired with both static and dynamic typing.
Being relatively new to functional programming, I expend lots of energy wondering “is this the functional way to do things?” Obviously recursion vs. iteration is pretty straightforward and it’s obvious that recursion is the functional way of doing things. But take closures for instance.
I’ve learned about closures using Lisp and I understand that closures are a combination of a function and an environment (sounds a lot like state and behavior). For instance:
(let ((x 1))
(defun doubleX()
(setf x (* x 2))))
Here we have a function doubleX that has been defined within the environment of the x variable. We could pass this function around to other functions and then invoke it and it will still be able to reference the x variable. The function can continue to refer to that variable, even if it is invoked outside of the environment where the variable has been defined. Many of the examples I’ve seen of closures look like this. Where setf is used to change the value of the lexical variable. This confuses me because:
1.) I thought setf was evil. Mostly because it causes side-effects and apparently they are also evil.
2.) Is this really “functional”? Seems like just a way of keeping global state and I thought functional languages were stateless.
Maybe I just don’t understand closures. Can someone help me out?
You're right, using closures to manipulate state is not purely functional. Lisp allows you to program in a functional style, but it doesn't force you to. I actually prefer this approach because it allows me to strike a pragmatic balance between purely functional and the convenience of modifying state.
What you might try is to write something that seems functional from the outside but keeps an internal mutable state for efficiency. A great example of this is memoization where you keep a record of all the previous invocations to speed up functions like fibonacci, but since the function always returns the same output for the same input and doesn't modify any external state, it can be considered to be functional from the outside.
Closures are a poor man's objects (and vice versa), see
When to use closure?
and my answer therein. So if you intend to use side-effects to manage state in your non-OO application, closures-over-mutable-state are indeed an easy way to do this. Immutable alternatives are "less evil", but 99.9% of languages offer mutable state and they can't all be wrong. :) Mutable state is valuable when used judiciously, but it can be especially error-prone when used with closures & capture, as seen here
On lambdas, capture, and mutability
In any case, I think the reason you see "so many examples like this" is that one of the most common ways to explain the behavior of closures is to show a tiny example like this where a closure captures a mutable and thus becomes a mini-stateful-object that encapsulates some mutable state. It's a great example to help ensure you understand the lifetime and side-effect implications of the construct, but it's not an endorsement to go and use this construct all over the place.
Most of the time with closures you'll just close over values or immutable state and 'not notice' that you're doing it.
Common Lisp and Scheme are not purely functional. Clojure is mostly functional, but still not purely. Haskell is the only language I know that is purely functional, I can't even mention the name of another one.
The truth is that working in a purely functional environment is very hard (go, learn Haskell and try to program something on it). So all these functional programming languages really what they do is allow functional programming, but not enforce it. Functional programming is very powerful, so use it whenever you can and when you can't don't.
Something important to know with the age that's coming is that anything that's functional is paralelizable, so it makes sense to avoid having side effects, or having in a smallest possible subset of your program as possible.