Why are most programming languages built on top of frameworks?

As programming languages continue to evolve开发者_高级运维, we see these programming languages that sit on top of frameworks such as Java or .NET, and that's good.

In your opinion, what are the best reasons to build a language on top of a framework?

Disclaimer: i'm not trying to prove something , i thought this was a good topic of discussion

In one word: Reuse.

Frameworks are large collections of classes, methods, etc., like libraries. Unlike libraries, they also enforce rules, so to speak, that define programming standards.

If you ever programmed COM objects by hand (ATL is even worse), or written C programs with the Win32 API, you'll understand easily that .NET is a good thing. It is a modernization of arcane difficult techniques with a certain lack of organization.

I can't agree with you: with the notable exception of C# and Java, languages are not tied to any "framework". Frameworks are just a huge collection of libraries, along with a philosophy, like every huge library. To me, this is just a word for marketing purposes. You can call .NET the "standard windows library" for instance.

Is the POSIX API a framework ? Is the collection of Python libraries a framework ? Is the C++ standard library, or Boost, a framework ? Is Qt a framework ? Is BLAS/LAPACK a framework ? Is Intel Threading Building blocks a framework ?

The world doesn't revolve around .NET or Java.

It's better to have one universal standard that is well written and well tested than for every programmer have to reinvent the same wheel over and over. The number of string classes written around the world before the likes of MFC's CString and Java/.net String classes was simply ridiculous.

Probably because:

If I have seen further it is by standing on the shoulder of the giants.

Not to mention the existing prospering community, the plethora of libraries etc. :-)

I'm happy to be the first persons that doesn't agree with the "one framework to rule them all" approach. I believe that engineers should use the right tools (available) to solve the problem. Believe is a good word since each software development approach/methodology has a great number of "believers" followed back by significant amount of pessimists :)

But, going back to the question... I see 2 main drawback of a framework approach:

1) It can be an overkill
Sometimes you just need a simple solution for a simple problem. You do not need a tool that solves/links with solutions for all problems of mankind.

2) "If you're not with use you're against us"
The fact is that it is impossible to provide a big, mature framework of Optimal/easy/adequate solutions for all problems it tries to address. So sometimes you need to introduce an external tool. This can be a pain in the ... For example invoking a Qt signals from a non-qt threads does not work out of the box (a failed to make it work at all). In this case you may find yourself "fighting" with the framework. Instead of making your life easier it can make you want to inflict severe damage upon yourself/other people :)

One of reasons for two previous points is that it's really hard not to make assumptions. Frameworks are made often on many assumptions that a programmer will do/use A, B, C... standard/framework component. Once hard-coded assumptions are introduced the chances that the framework will be modular are falling down as a piano from the 10th floor :)

On the other side the "right tool for problem" approach allows a programmer to focus on one problem and implement it well. By saing well I mean:
1) Data agnostic For example (C++) if you work with strings do not a assume a string type. Allow user to work with different strings from different frameworks: QString, wxString, std::string...
2) Policy agnostic/extendable
Programmer may like the overall way the frameworks implements something, but may find that one tiny aspect renders the framework unusable for him. That's why framework user should have the ability to introduce his own policy in some key parts
An example of family sharing this approach are internal/external DSL implementations (Domain Specific Language). A concrete example(C++) is a Blitz++ library.

All I said before is also valid for the high level languages. For example there are may languages build on the Java Virtual Machine (Scalla to start with).

Hope I made some good points. Best Regards,
Marcin

Perhaps I misunderstand the question, but .NET isn't built on top of a framework. In fact, it's the other way around. Frameworks often extend languages as the languages become more powerful and they often ship in the same pack with language compilers. However, there are also Domain-Specific Languages which are built on top of an existing framework and an existing language. Technically these are not languages but more of a scripting API. C#.NET and VB.NET language specs haven't actually changed all that much with the exception of optional parameters, named arguments, co/contra variance and a few others. It's the framework around them that recently gave us expressions, linq and etc.

EDIT 1: Unless we consider virtual machines such as JVM a framework, than i can see how that could be true.

EDIT 2: Having understood the question, the answer is simple. It's portability (in terms of compiling to an intermediate language when you're dealing with Java or .NET environments) and the ability to leverage the power of the framework.

Because that frameworks provides reusable components that are essential for any high level language implementation: FFI, GC, JIT, linker, debugger and the rest of toolchain. And it's not fun at all to re-implement all that components from scratch.