James Gosling Interview (opens in new tab)

It definitely isn't[1]. Python has both floats and integers. He's sort of right though that it doesn't have "true integers ... which ... improve performance" since Python's numeric types are boxed and not exactly fast (unless you use numpy).

Also, which "many other" languages have only doubles, aside from JavaScript?

[1] https://docs.python.org/3/reference/datamodel.html#the-stand...

I would guess he might be talking about how integers are objects in python, and stored in heap, rather than being stored as values directly on the stack. I haven’t looked, but it could also be in python that all numeric types are stored according to IEEE 754 before being unboxed to the indicated type.

Edit: I said Tcl, but that has the opposite problem: integers are fine, but floating point is problematic because everything is strings. Updated below to remove Tcl.

I don't think this is true of most languages; only for Lua that I know of. And it causes problem: if you send a 64-bit ID to Lua, which represents it as a double, it will subtly change the last few bits. Then when you go to look up something with that ID, you get the wrong item.

Most languages don't have that problem.

It’s a pedantic statement. Correct for the base language, but numpy supports 16, 32, 64, and maybe extended/128 bit too. It’s the kind of nonsense argument from language flamewars that has no relevancy for practical use cases.

Anyway, java does not have unsigned int, so there you go.

Edit: if he claims that int-is-float like in javascript, he’s just flat wrong.

An if statement and a function call have different forms in C. They have the same form/syntax in lisp. It's like the power of everything is a file/bytestream in unix. Because everything has the same form (uniform interface) then if you write a tool it can be made to work on everything. Grep works with all processes because they all have a uniform output stream. Macros in lisp work with all constructs in the language. Usually the basic form has to be quite primitive to do this. If it is too primitive you end up with what is known as a "turing tar-pit". But people can fall in love with the power of this uniform interface so much that they do not realize that they have ended up with a tar-pit at a high level. This can happen with macros but it doesn't have to.

I may be imposing my own views on his wording, but my interpretation is that his concern is related to the fact that macros have similar syntax to everything else in the language. Consider these two forms:

> (and a b c)

> (and* a b c)

Can you tell by looking that the the first is a macro and the second is a function? The first short circuits and evaluates only the argument forms it needs and the second always evaluates all three. That's a big difference, and not at all obvious from the syntax. In fact, it's hidden by the syntax, because the syntax is exactly the same for each.

Macros are part of the power of Lisp, but they change the normal rules of evaluation (the semantics) in ways that are not necessarily obvious unless you know the specific definitions behind each symbol in function position.

I am also not sure, but in compiler design semantic analysis includes checking to see variables match their types, and obviously lisp macros are partially so powerful because their is no type checking.

For me this was the biggest challenge when I was introduced to lisp: everything is just a list. Powerful, yes, but in other languages the ground felt firmer underneath my feet when I knew a class was a class, a struct was a struct, and array was an array, all with their own unique syntax. In lisp everything just looks the exact same. That is part of why it is so powerful, but at the cost of semantical references that can help users understand a lisp program.

I'm not so sure about that, yes it's an important language and has oficial support from Google, but by the amount of usage we can say Dart ( in Flutter ) also "replaced" Java on Android.

Don't get me wrong I HATE Java on Android and everything GUI related, but I'm don't think Java will be replaced anytime soon.

Has it really? (Totally honest question, I don't follow that space well.) If Some Random Company is starting a new Android app today, is it more likely to be in Kotlin than Java? That's cool, if so.

His "true parallelism" means two (or more) actual simultaneous executions (threads, processes, etc.) occurring at the same time (redundant with simultaneous, for emphasis). This is contrasted with concurrency (see Pike's talk Concurrency is not Parallelism [0] for an example of how this line is drawn), which may or may not be implemented with "true parallelism". Coroutines, the example Gosling gave, often do not actually have simultaneous execution.

That Erlang forces some synchronization that other languages may not does not affect the ability to (with versions of Erlang since, what, 2007 or 2008?) make use of SMP for simultaneous execution of processes on separate cores or processors.

See also OpenMPI for an example of a distributed programming system that also can't share memory without copying it. Though in its case it was across physical nodes (and so the need to communicate was more obvious, they physically didn't share memory anyways). Still true parallelism.

[0] https://blog.golang.org/waza-talk

Because anything described as "true X" is a fallacy and everyone has different views on what "true" is, what "parallelism" is and what "true parallelism" is. Sure, if you define "true parallelism" as "share memory between cores without copying it", then Erlang doesn't give you that.

It seems that James Goslings view of "true parallelism" is "let you take advantage of multiple processors", so with that frame of mind, Erlang does give you "true parallelism".

> Coroutines kind of magically sidestep some of the naughty issues in true parallelism. And for me, one of the problems with coroutines, which is why I haven't used them in a long time, is that they don't actually let you do or let you take advantage of multiple processors. You can't do true parallelism.

> But as soon as you've got one of these coroutine-based languages and you try to exploit multiple processors, if you're doing a lot of coroutine-type operations and you don't have enough processors, you're just saturating one processor.

Yeah, that seems like a strange sentence coming from a language designer who should know better. Just on the surface there is the differences of statically typed VS dynamic, class-based VS prototype-based, the implicit global state in JS, JS having first class functions and so on.

Longer quote seems weird as well

> To really get the performance improvements you see, it helps dramatically to have a statically-typed language. For dynamically-typed languages, like Python, it's really, really hard. And often, what people end up doing is adding annotations to the language so that you get languages like TypeScript, which is essentially JavaScript with type annotations. And it's really funny because JavaScript is essentially Java with the type declarations removed. So TypeScript is essentially Java with permuted syntax.

He seems to be saying that TypeScript leads to faster code execution as TypeScript has types, but fails to understand that TypeScript still compiles to JS and the browsers run JS without types, so should have the same performance as just writing JS directly (probably less performance, as TSC adds bunch of wrappers and other unnecessary stuff you would avoid if writing vanilla JS)

other than curly braces, there's really no much similarity between Javascript and Java.

Gosling comes by his preferences or biases in a pretty honest way, by having put thousands of hours of work into Netbeans.

Is Eclipse modern? Do new programmers and projects use it? It has been in decline for years.

That’s not a helpful way of looking at it I think. Ideas don’t exist in isolation, and thus old experiments have to be carefully analyzed to extract what’s still true out of it. Often times it’s just cheaper to redo the experiment.

This is true across the board for engineering. It’s hard to build something that survives long prolonged contact with engineering realities. Computer architectures change. How things are done efficiently changes. The set of trade-offs we choose to make changes as the underlying business shifts or better business models are discovered. And heck, businesses can be cyclical for no better reason than humans are naturally cyclical in trends (see fashion)

Stroustrup was another big Simula fan of course and drew a lot of ideas from it for C++ - it is certainly a very influential language it would seem.

The concept certainly predates Haskell by a few decades, but I haven’t found the origin of the phrase.

I tried to find a copy of this SNOBOL paper from 1973[0] to see whether it occurs there, but no luck so far. It doesn’t appear in the original COMIT paper[1].

[0]: https://dl.acm.org/doi/10.1145/361952.361960

[1]: http://www.catb.org/~esr/comit/comit-paper.html

Haskell copied a huge amount of its core concepts from ML, and even then, ML was very much a collection of prior experimental concepts with a new type system on top.

Because he has done very interesting software engineering which is used in the real world to solve real problems.

I agree.

The fact that he inflicted Java upon the world is proof enough.

This might be related to him having developed his own emacs implementation.

https://en.wikipedia.org/wiki/Gosling_Emacs