Earlier quoted context omitted.
COBOL is not around in anything interesting, and trust me go is not going to be used to build anything that we'll use in 20 years.
Do I hear "containers are a temporary fad"?
Yep
Programming Language Memory Models
41–50 of 101 posts
Re: Programming Language Memory Models
#42Earlier quoted context omitted.
They are not too complex for "languages intended for dilettante developers": they can (and should) use sequential consistency or locks everywhere.
How many programmers do you know put locks around polling varibles for seemingly no reason (as they are not cognizant of the memory model)?
Well, while it may appear gatekeeping, maybe those dilettante developers should be using something else instead, like BASIC?
Re: Programming Language Memory Models
#43In a 100 years the main languages used will still be C on the client (with a C++ compiler) and Java on the server. Go has no VM but it has a GC. WASM has a VM but no GC. Eveything has been tried and Java still kicks everythings ass to the moon on the server. Fragmentation is bad, lets stop using bad languages and focus on the products we build instead. "While I'm on the topic of concurrency I should mention my far to…
I'm sorry is this comment from 1998? I've been working in software for over a decade, and I haven't seen server work being done in Java in ages. From my perspective, Go in the context of serverless programming seems to currently be the best choice for server-side programming. In the next 20 years I expect Go will be supplanted by a language which is a lot like go (automatic memory management, simple, easy to learn &…
And I haven't seen server work done in C++ since 2006, we keep replacing those systems with Java and .NET ones.
To each its own.
Re: Programming Language Memory Models
#44Earlier quoted context omitted.
How many programmers do you know put locks around polling varibles for seemingly no reason (as they are not cognizant of the memory model)?
Well, while it may appear gatekeeping, maybe those dilettante developers should be using something else instead, like BASIC?
CPython has a pleasant memory model from what I've heard :)
Re: Programming Language Memory Models
#45Earlier quoted context omitted.
> To solve that problem, the practitioner only needs to know that "mutex.lock()" This is true, but they do not know that. If you do not give some kind of substantiation, they will shrug it off and go back to "nah this thing doesn't need a mutex", like with a polling variable (contrived example).
Can you explain what you mean by a "polling variable" needing a mutex? Usually polling is done using atomic instructions instead of a mutex. Are you referring to condition variables?
In a lot of code I've seen, there are threads polling some variable without using any sort of special guard. The assumption (based, I assume, on how you really could get away with this back in the days of single-core, single-CPU computers) is that you only need to worry about race conditions when writing to primitive variables, and that simply reading them is always safe.
Re: Programming Language Memory Models
#46Earlier quoted context omitted.
which are very similar to global variables, but the compiler doesn't know that they're global Since as you say, they are very similar, wouldn't it be reasonable to assume for access purposes that they are effectively global?
Lets do this example in Java (but it should be simple enough that C#, Python, Javascript and other programmers would understand it). public void myFunction(FooObject o){ o.doSomething(); } How does the compiler know if "FooObject o" is a singleton or not? That's the thing about the "Singleton" pattern, you have an effective "global-ish" variable, but all of your code is written with normal pass-the-object style. EDIT…
Is there anything special about singletons here?
In Java, there's no real difference between a singleton and any other object. A singleton is an object that just happens to have a single instance. Practically speaking, they're typically used as a clever design pattern to "work around" Java's lack of language-level support for global variables, so there's that. But I think that that fact might not be relevant to the issue at hand?
The more basic issue is, if you have two different threads concurrently executing `myFunction`, what happens when they're both operating on the same instance of `FooObject`?
Re: Programming Language Memory Models
#47A lot of the complexity comes from the lack of expressivity in languages to relate variables (or data structure fields) semantically to each other. If there was a way to tell the compiler "these variables are always accessed in tandem", the compiler could be smart about ordering and memory fences. The idea to extend programming languages and type systems in that direction is not new: folk who've been using distribute…
That's Java's Object.lock() mechanism. All variables inside of an object (aka: any class) are assumed to be related to each other. synchronized(foobar_object){ baz(); } ensures that all uses of foobar_object inside the synchronization{} area are sequential (and therefore correct). -------- The issue is that some people (a minority) are interested in "beating locks" and making something even more efficient.
In Java, any object can be used to synchronize any data, e.g.
synchronized(foobar_object){ foo(); }
synchronized(foobar_object){ bar(); }
synchronized(foobar_object){ baz(); }
The only time synchronized(explicit_object) relates to anything else is when also using the keyword where `synchronized void foo()` is equivalent (with a minor performance difference) to `synchronized(this) { ... }` wrapping the entire body of the foo method.
Re: Programming Language Memory Models
#48These "memory models" are too complex for languages intended for dilettante developers. It was a disaster in Java/C#. Not even more than a handful of programmers in existence know in depth how it works, as in, can they understand any given trivial program in their language. At best they only know some vague stuff like that locking prevents any non visibility issues. It goes far deeper than that though (which is also…
> These "memory models" are too complex for languages intended for dilettante developers.
It would be nice if sometime we stopped pretending that beginners are too slow to know/understand things and instead faced the fact that their instructors and mentors are bad at teaching.
Re: Programming Language Memory Models
#49Earlier quoted context omitted.
Can you explain what you mean by a "polling variable" needing a mutex? Usually polling is done using atomic instructions instead of a mutex. Are you referring to condition variables?
In a lot of code I've seen, there are threads polling some variable without using any sort of special guard. The assumption (based, I assume, on how you really could get away with this back in the days of single-core, single-CPU computers) is that you only need to worry about race conditions when writing to primitive variables, and that simply reading them is always safe.
Okay but the poster mentioned a mutex, which would not be a good way to go about polling a variable in Java. All you need to guarantee synchronization of primitive values in Java is the use of volatile [1]. If you need to compose atomic operations together, then you can use an atomic or a mutex, but it would not occur to me to use a mutex to perform a single atomic read or write on a variable in Java.
[1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html...
Re: Programming Language Memory Models
#50Earlier quoted context omitted.
> In the next 20 years I expect Go will be supplanted by a language which is a lot like go (automatic memory management, simple, easy to learn & write and performant enough) but with the addition of algebraic data types, named parameters, and a slightly higher level of abstraction. I'd love for this to be Crystal: https://crystal-lang.org/ > I haven't seen server work being done in Java in ages. In the meantime, I've…
I have a feeling it's going to have C-like syntax and frankly I hope so because using an `end` keyword instead of braces makes no sense to me.
Arguably using curly braces to delineate blocks makes no inherent sense either. We just do it because that's what everybody else does.