4 ms·

> If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes. Counterexample: the JVM, which runs quite a

> If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes. Counterexample: the JVM, which runs quite a few languages, including some that were created without any consideration thereof (python, ruby, lisp, perl).

lalo2302 9y ago
> If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes. Example: Elixir and Erlang on BEAM VM
chubot 9y ago
Yeah I think the JVM is a special because of Hotspot -- a state-of-the-art JIT compiler. I'm pretty sure that without a JIT you will not get decent performance on compiling one language to a VM designed for another language. Also, I think the JVM "required" at least one modification for dynamic languages? I recall something about JRuby and invokedynamic bytecode, but I don't know the details: https://www.infoq.com/articles/Invokedynamic-Javas-secret-weapon https://www.infoq.com/articles/Invokedynamic-Javas-secret-we... As another counterexample, I've heard that VB.NET is just C# in a different syntax, more than it is VB6. That is, when it moved to the CLR, the language changed.
- WorldMaker 9y ago
  VB.NET is more like VB6 than C#. The problems with the vocal minority in the VB6 community not moving to VB.NET had mostly nothing directly to do with the CLR. (The break in backwards compatibility, and inability to just "upgrade" old code, in a language that hadn't a major break since VB3 was more impactful, I think. That was more due to the VB team trying to clean house and remove anti-patterns than the CLR's fault.) The CLR has just as many languages, including dynamic languages, supported as the JVM.
  - meredydd 9y ago
    VB.NET is shaped like the CLR, just like C#. (Similarly, Java is shaped like the JVM.) It is possible to mechanically transform VB.NET code into C# code. Heck, I'd bet they both parse to the same AST. They are very, very similar languages, with the exception of syntax. The upshot is that writing VB.NET involves understanding everything you need to understand to write C#. All the syntax is VB6-flavoured, sure, but it still involves making people learn about classes, this year's flavour of Windows UI components, and so on. What's more, you have to do it all in an industrial-strength IDE, with all the complexity that brings. (Don't get me wrong - Visual Studio is more or less my gold standard for a usable industrial-strength IDE. But if you stand it next to VB6, you'll see how much more you need to understand just to get to editing code is noticeably larger. It can be invisible to people like you or me, who have already absorbed these concepts, but it's real.)
    - WorldMaker 9y ago
      VB1-6 encouraged classes. The fact that OO was not more popular in VB was a failure to communicate. VB.NET didn't add classes, it removed the anti-pattern that was grab-bag modules. Again, that's much more of a backwards compatibility problem than a CLR problem. The VB team could have kept modules and still targeted the CLR, they just chose not to in the hopes of cleaning up some of the worst patterns in VB. Just because you can "mechanically transform" code between two languages doesn't make them the same language. Compilation is a mechanical transformation to machine code, but you don't see anyone arguing C++ is the same language as Assembly. (Did you ever look at the output of such mechanical transformations? The results were always weird, lacking proper idioms in the target language. Just like machine translations of spoken languages, I wouldn't rely on them without a lot of work to clean them up and verify them.) Yes, VB.NET and C# share many (but not all!) components of the same AST, but so too now does F# as it is being brought over to the Roslyn compiler platform. Shared AST components also do not make a language "the same", because of that fun word "abstract" in AST. Just as most languages can be described in a BNF variant, fall into some variation of the category Context-Free Grammar, represent similar Pushdown Automata, etc. The underlying tools are very much the same across the vast spectrum of languages, but that doesn't mean all languages are the same/interchangeable. Also, Visual Studio is a direct successor to the VB6 IDE. Visual Studio .NET shared a lot of code with that IDE. I'd be surprised if VS today didn't have at least some code inherited down the many years from that predecessor (certainly plenty of ghosts of it in source control). The VB6 IDE was considered "industrial-strength" in its time, too. Given there's a free Community Edition of Visual Studio, and VB6 was never cheap, arguably the barriers to new developers to "just get to editing code" are at the lowest they've ever been, complexity or not. (Nostalgia is a weird fuzzy thing.)

lalo2302 9y ago

> If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes. Example: Elixir and Erlang on BEAM VM

chubot 9y ago

Yeah I think the JVM is a special because of Hotspot -- a state-of-the-art JIT compiler. I'm pretty sure that without a JIT you will not get decent performance on compiling one language to a VM designed for another language. Also, I think the JVM "required" at least one modification for dynamic languages? I recall something about JRuby and invokedynamic bytecode, but I don't know the details: https://www.infoq.com/articles/Invokedynamic-Javas-secret-weapon https://www.infoq.com/articles/Invokedynamic-Javas-secret-we... As another counterexample, I've heard that VB.NET is just C# in a different syntax, more than it is VB6. That is, when it moved to the CLR, the language changed.

WorldMaker 9y ago
VB.NET is more like VB6 than C#. The problems with the vocal minority in the VB6 community not moving to VB.NET had mostly nothing directly to do with the CLR. (The break in backwards compatibility, and inability to just "upgrade" old code, in a language that hadn't a major break since VB3 was more impactful, I think. That was more due to the VB team trying to clean house and remove anti-patterns than the CLR's fault.) The CLR has just as many languages, including dynamic languages, supported as the JVM.
- meredydd 9y ago
  VB.NET is shaped like the CLR, just like C#. (Similarly, Java is shaped like the JVM.) It is possible to mechanically transform VB.NET code into C# code. Heck, I'd bet they both parse to the same AST. They are very, very similar languages, with the exception of syntax. The upshot is that writing VB.NET involves understanding everything you need to understand to write C#. All the syntax is VB6-flavoured, sure, but it still involves making people learn about classes, this year's flavour of Windows UI components, and so on. What's more, you have to do it all in an industrial-strength IDE, with all the complexity that brings. (Don't get me wrong - Visual Studio is more or less my gold standard for a usable industrial-strength IDE. But if you stand it next to VB6, you'll see how much more you need to understand just to get to editing code is noticeably larger. It can be invisible to people like you or me, who have already absorbed these concepts, but it's real.)
  - WorldMaker 9y ago
    VB1-6 encouraged classes. The fact that OO was not more popular in VB was a failure to communicate. VB.NET didn't add classes, it removed the anti-pattern that was grab-bag modules. Again, that's much more of a backwards compatibility problem than a CLR problem. The VB team could have kept modules and still targeted the CLR, they just chose not to in the hopes of cleaning up some of the worst patterns in VB. Just because you can "mechanically transform" code between two languages doesn't make them the same language. Compilation is a mechanical transformation to machine code, but you don't see anyone arguing C++ is the same language as Assembly. (Did you ever look at the output of such mechanical transformations? The results were always weird, lacking proper idioms in the target language. Just like machine translations of spoken languages, I wouldn't rely on them without a lot of work to clean them up and verify them.) Yes, VB.NET and C# share many (but not all!) components of the same AST, but so too now does F# as it is being brought over to the Roslyn compiler platform. Shared AST components also do not make a language "the same", because of that fun word "abstract" in AST. Just as most languages can be described in a BNF variant, fall into some variation of the category Context-Free Grammar, represent similar Pushdown Automata, etc. The underlying tools are very much the same across the vast spectrum of languages, but that doesn't mean all languages are the same/interchangeable. Also, Visual Studio is a direct successor to the VB6 IDE. Visual Studio .NET shared a lot of code with that IDE. I'd be surprised if VS today didn't have at least some code inherited down the many years from that predecessor (certainly plenty of ghosts of it in source control). The VB6 IDE was considered "industrial-strength" in its time, too. Given there's a free Community Edition of Visual Studio, and VB6 was never cheap, arguably the barriers to new developers to "just get to editing code" are at the lowest they've ever been, complexity or not. (Nostalgia is a weird fuzzy thing.)