Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am curious about what tools are used to build the next version of themselves.
For example, Delphi has long claimed that "Delphi is written in Delphi".
I assume Visual Studio is written using Visual Studio.
What are some other examples of tools that written in themselves?
Interestingly, the VB.NET & C# compilers themselves are written in unmanaged C++ (leading to the C++ team's T-Shirt: "My compiler compiled yours"). The C# team hopes to have a fully managed-C# hosted C# compiler for VS2010.
Bjarne Stroustrup mentioned in The Design and Evolution of C++ that the first C++ compiler was written in C++.
I've just noticed this is also a question in his FAQ:
The first C++ compiler (Cfront) was
written in C++. To build that, I first
used C to write a "C with
Classes"-to-C preprocessor. "C with
Classes" was a C dialect that became
the immediate ancestor to C++. That
preprocessor translated "C with
Classes" constructs (such as classes
and constructors) into C. It was a
traditional preprocessor that didn't
understand all of the language, left
most of the type checking for the C
compiler to do, and translated
individual constructs without complete
knowledge. I then wrote the first
version of Cfront in "C with Classes".
This is off-topic, but strictly speaking, it is an example of a tool which builds itself.
The reprap - an open-source 3d prototyping machine, which recently gave 'birth' to "its first complete working replicated copy".
I love this kind of stuff.
Generically speaking, C compilers are usually written in C... *nix kernels are compiled on *nix, etc.
Also, there's the pypy project which provides a Python interpreter written in Python.
When gcc (the Gnu C compiler http://gcc.gnu.org/) was not available widely, you had to compile it from source, compiling stage1 compiler, then compile stage2 with stage1, till you have your final compiler. I assume it must be the same today.
Here is another example: Mono's C# compiler is self hosting - i.e. it's written in C# and used to compile itself.
Dog fooding refers to the more general practice of a company using its own product internally, especially during its development.
Lots of folks like to look at how Lisp can be implemented in Lisp.
Squeak is a Smalltalk-80 implementation written in itself.
even its virtual machine is written entirely in Smalltalk making it easy to debug, analyze, and change.
Sun's Java compiler has long been written in Java. However, recent work is writing a JIT compiler in Java as well. This is the JVM component that converts Java byte code to native processor instructions.
We use to develop using RealBasic. The IDE is written in itself, or so I've been lead to believe.
ghc, the Haskell compiler, is mostly written in Haskell.
tcc is another self-hosting C compiler for x86 and ARM. Its claim to fame is being, well, tiny (100k or so for preprocessor, compiler, assembler, and linker).
I would assume that pretty much any tool that's part of the typical development process would be involved in its own development, to whatever extent possible. This includes:
certain programming languages, especially compiled ones
IDEs
text editors
version control systems
bug trackers
build systems
If you're on a team building one of these tools, and you're not developing it for a specific niche that doesn't apply to your team, I don't know why you wouldn't use it to build itself. Having developers be users of the product is one of the best ways to find possible improvements.
For the AmigaOS there was a third party Basic interpreter (don't remember the name) for which you could later buy a compiler. The compiler was delivered as source, so you had to use the interpreter to run the compiler to compile itself...
To cite Kent Beck:
...it may seem a bit like performing brain surgery on yourself.
Visual Studio and Team Foundation Server build themselves. It's called dogfooding, a term which if not originating in Microsoft, it certainly likes
Oracle Application Express is a web application development tool that is built in itself.
Eclipse IDE is generally built and developed using Eclipse IDE.
It is fairly typical to have a languages compiler written in its own language. This is called self-hosting or bootstrapping.
Maven2 is built using Maven2.
Ok, it's not built (i.e. written) using itself, as it is a tool to build (i.e. compile) project, but it is using its own code to compile...
I was amazed with JSLint
In short it has been described as Javascript "compiler" using javascript.
I am building an IDE-based code generator, and I am using it to build itself. If fact, as Stroustrup did, I am first building a valid generator model and using a pre-processor to build the final C++ code to compile. Once I have a good working version of the IDE, I'll start using it to build further versions of itself.
It's like giving a new dimension to the meaning of "recursive programming"!
AFAIK does the OpenJDK build itself first with the installed java and afterwards with itself.
Naturally the Jetbrains team uses its own IDE IntelliJ IDEA to develop this IDE.
I assume this is true for most IDE vendors.
As far as I know, when building EMACS from source, all of the ELISP code is bootstrapped. I found that quite noteworthy.
Not quite what you're asking for, but the entire development environment for Revolution http://www.runrev.com is built using Revolution itself, and the source (except for small parts that enforce the license) is completely exposed in source form. So if you don't like the way the dev environment is implemented, you can change it. Find a bug, fix it. You can also easily build additional development tools and integrate them.
Ada and Forth
I gave the Smalltalk-80 answer an uptick. Best, most elegant example I can think of. The question also reminds me of a slightly related problem that used to be popular: write a program that outputs itself. Not the same level of bootstrapping, but a fun little programming puzzle for your amusement. Maybe not possible in all languages?
The old Watcom C/C++ compiler was built using itself.
Kragen Sitaker's Ur-Scheme is a fine example of a small nontrivial compiler written in itself. That page links to several more good sources in that vein.
Related
I apologize if this question is out of topic, but it's a matter of accessibility for C++14 programmers.
Today i've updated Qt v5.4 on my PC (Windows 8.1/64bit/x86) and it support now the gcc compiler v4.9.2. But i've seen that constexpr relaxation (which really interest me) is available since gcc v5.1.
A search on google shows that :
clang is the better compiler for C++14 latest features (v3.6 is even dealing with experimental C++17)
clang is not easily suitable with Qt libraries
both gcc and clang "datas" are downloadable but i'm not an expert...
So i'm asking how to get a free IDE on Windows 8.1 with an adequate compiler.
If i dismiss Qt for my C++14 experiments, is Codeblocks a better solution ?
Does any else IDE already include an adequate compiler during the installation ?
Where can i find help to install such a compiler ?
Your question is poorly phrased -- for the most part, ide's and compilers are decoupled -- the exception that comes to mind is visual studio, which is an ide that is tightly coupled to microsoft's compiler.
Whether you chose codeblocks, or eclipse, or use a simple text editor, you should be able to choose your compiler fairly easily, and independently of your ide. So you have two independent questions: Where can you get a free compiler for windows with high standards compliance, and what's a good IDE with which to use that compiler.
I'm not a windows person, but very simple, one-file projects, you might actually find it easy to use a gnu-linux environment, which you can do under windows by using cygwin:
http://preshing.com/20141108/how-to-install-the-latest-gcc-on-windows/
This may seem daunting at first, but let me tell you the benefits:
you'll learn the difference between your compiler and editor.
As long as you are only experimenting with the standard, you may find it simpler to get set up than using an ide.
You'll have to learn about the c++ compile process (compiling, linking, possibly preprocessing), not about ide specific stuff.
This will prevent you from conflating ide-specific stuff with c++ stuff, as you have done in your question. As you begin working with projects you'll probably find an ide an advantage, but in the beginning staying close to the raw tools may give you the fastest learning return on investment.
After install cygwin, all you have to do is write your code (using a syntax highlighting editor like gedit or emacs is suggested), and then run
g++ -std=c++14 filename.cpp
to compile your code.
You should be able to use clang under cygwin as well.
I downloaded Lazarus, but have worked with Embarcadero Delphi IDE too. I have a question about building cross-platform Delphi applications.
How can I build them under win32 environment? I read the wiki from Lazarus site, that explains how to do it, but I still do not understand it. Is is possible to build and compile application under win32 environment for Linux and MacOS? If it is possible, can someone explain ste-by-step how to do it exactly.
EDIT:
Now is the time for talking about the new XE2 version of the Delphi IDE I think :)
Thanks
What you're asking for already exists in the lazarus wiki site, you need to read these articles.
Multiplatform Programming Guide
Cross compiling
Cross compiling for Win32 under Linux
How to Write Portable Code (nice doc from Marco van de Voort)
Buildfaq
While crosscompiling to a non windows target is possible (and not that hard), getting used to fpc/lazarus and crosscompiling in one first step is a bridge too far. This because Linux is not a very homogenous target and dealing with this variation requires some understanding how libraries and linking works on Linux. This defeats one-button downloadable cross-compile setups to "general" linux. I know, such one-button thingies that work out of the box for everyone would be great, but it is just not going to happen (or only forvery limited distribution-version combinations)
Crosscompiling with FPC is not extremely difficult or rocket science, but the amount of jargon and details can flabbergast uninitiated people, and without background knowledge it is hard to diagnose problems as a result of minor misconfigurations
I recommend to first familiarize yourself with Lazarus/FPC, and only then make the crosscompilation leap. (and the already mentioned buildfaq names some reasons).
Bottomline: install lazarus on Windows and start porting your app. If that succeeds, start using a linux install (or VM) to familiarize yourself with Linux, and Lazarus under it. You'll need a linux install anyway to test.
Only then start thinking about crosscompiling to speed up the process.
CodeTyphon is a powerful Lazarus/FPC one click easy installation package for cross platform native development. It already supports 4 CPU/OS hosts (Win32, Win64, Linux32, Linux64), and 16 CPU/OS targets (arm-Wince, arm-Linux, arm-Embedded, arm-gba, arm-nds, i386-Win32, i386-Linux, i386-FreeBSD, i386-Haiku, x86_64-Win64, x86_64-Linux, x86_64-FreeBSD, powerpc-Linux, powerpc64-Linux, sparc-Linux, sparc-Solaris). More are supported in Lazarus/FreePascal, but others are not yet integrated in CodeTyphon. Did I mention that it is free? One code to rule them all ;-)
The point is that you don't have to waste days for setting up your cross platform environment, since someone has already done the hard work for you.
As perhaps you know already, most probably the next version of Delphi will be cross-platform. Also, here are some polls on the matter.
While writing a cross-compiler isn't a thing which interests us very much now, porting a library which was/is Windows-tied to multiple platforms, certainly does.
You can think, for example at VCL (Delphi's standard library). While it was designed for Windows only, it has value in it, and, of course, there are huge codebases which depend on it.
The question is:
Which would be the best approach to made an application / library cross-platform aware ensuring a smooth conversion / upgrade path (as much as possible of course)?
I stress it again, we are not interested which is the best way to do cross-platform development only (there were questions on this theme). We are interested also in yet another requirement: The old code base / installations management.
PS: Experiences and/or methodologies from similar situations with other languages (eg. C/C++) which are regarded as standard practices are welcomed.
Thanks in advance.
Visual component developer's perspective:
Add levels of functionality to your code, so as to be able to add another platform without changing the "Core" of the component.
The compiler hopefully will have a platform switch. (Preferable more than one, working in conjunction with each other. ex. Windows/ARM, Windows/386, OSX/Cacao/386, Linux/Gnome/386).
The Layout structure might look something like this.
ComponentJ.pas
Linux\ComponentJ.pas
Linux\Gnome\ComponentJ.pas
Linux\KDE\ComponentJ.pas
OSX\ComponentJ.pas
386\ComponentJ.pas
ARM\ComponentJ.pas
As an Application Developer:
I'll start by moving all WIN API calls in my code into a group of libraries in a Windows directory as to be able to IFDEF it at library level and translate it into another platform I'd like to support as soon as the compiler becomes available, but only as I come across them.)
This will also add the possibility to add adapters easier for the new platforms.
It in any case is good practice to remove possible dependencies into a central place.
IMHO you can't build a xplatform Delphi and ensure a smooth transition for current VCL applications. It won't work. VCL was (luckily, because it allowed for great applications) designed with Windows in mind, and trying to design a compatible library working on a different platform would just mean longer development cycles and lots of compromises. The outcome will be a library noone would wish to use. Look at what happened to VCL.NET: it was the wrong choice. And it was working on the same OS!
We know that targeting non-Windows platform with native applications needs a native GUI library. We don't care about creating a GUI from scratch, for our application it's the way to go, we don't need Windows GUIs with all their standards under a different OS using different standards - we need to be able to code a fully native GUI for the target OS.
Other applications may survive a GUI porting, but in the long run you don't get a real xplatform tool - you get a tool that may compile for other platforms but brings one platform paradigms to others - and it will also be not welcome by "native" developers on other platforms. If you're a Linux or Mac developer, why should you learn how to work with a library that carries its Windows inheritance to your platform? You'd find it a pain in the ass. If Embarcadero wants to sell XDelphi outside actual developers base, it has to offer much more than a new CLX.
I will pull from some ancient experience in making a code base cross compilable between windows and dos (Delphi 1/Turbo Pascal 7). The rule of thumb was to separate code into multiple units. Try to code WITHOUT using windows, messages or any visual components. If you find you need to make a call to one of these, then place that call in another unit and write a proxy (abstract class that you descend from works well) to dispatch the calls through. When a cross compatible version is released, all that you should have to do is code the other side of the proxy for the new target.
If you're designing a form based system, then try to stick with as many of the standard components as possible. NEVER implement any "business" rules directly in an event, instead place them in another unit and call into the other unit to perform the logic.
Now, there will definitely be changes required to get your final project cross compatible, but by following these simple patterns you should be able to greatly reduce the amount of work it will take.
Experience so far has shown that the best way to get a Delphi app compatible with future versions is to stick to pure Delphi components, and use nothing third party. Such an app will probably suck, but that's how it seems to me. I use lots of third party components, and the apps are great and successful. But the chances of them moving to this future too are not certain, and that may cause problems with such changes, but I'd rather have a great app now and have the problem than have a poor app now and not need to worry about it.
Compromises should not be done too much to make VCL compatible with Linux and Mac. Windows is VCL's root. I'll prefer a new and very clean GUI framework, even though without any backward compatibility. Make VCL fatter and fatter isn't a good idea!
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
Well, look at freepascal and lazarus
I don't get it. All .NET looks the same to me providing we don't use any third party.
Delphi using standard control is already fully functional but your app would look
like thousands of others.
I think Embar should go for PDA, IPhone, Andriod as Windows desktop already eat about
98% of the market.
Mac is expensive and Linux is no cost at all. No use to go for Mac and Linux. Not worth
the investment.
Well, aside the things said - thanks all - I do think that there we need some additional things:
we need tooling to do the necessary conversions
we need tooling to help us in programming against a (some form of) MVC pattern
Simply pick the latest 4.6 QT and add good integration betwen the Pascal and the QT library.
They have done it before (in the Kylix times). The QT is such powerfull these days.
I believe that QT is even better then VCL and at least 10 times more frequently updated and fixed.
So the plan is simple:
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
and you will have a first-class natively looking applications on all platforms.
My opinion:
Make cross platform compiler (OS x/Linux/ embedded solutions?/ symbian?). Maybe add ability to compile/convert pascal code into portable c/c++ code to build then on embedded platforms.
RTL have to be separated into cross-platform layer and native layer (as for JCL).
Add new core components for cross-platform compatibility and native components for each supported platform (QT for ex)
Add translation utilities to create/convert between platform's components, for ex: to convert pure windows form into mac os x cocoa's form.
All windows hierarchy of components have to be only upgraded to support x64 with maximum backward compatibility. All cross-platform component have to be in parallel hierarchy.
Next version of cross platform solution can be refactored and can include migration/convertion utility. Due to minimum codebase of cross-platform solutions, hierarchy and classes for cross platform can be heavily changed from version to version to achieve best architecture.
sorry for my English - not a native language (Russian is)!
Make C/C++/Delphi compilers that targets OSX/Linux
Make C/C++ compiler that can be Boosted
Write new VCL-Presentation Foundation (VGScene/WPF alike)
it should not be backward compatibile! Delphi IDE should be
written with such VCL-PF
Component Library should stay as it is (but with improved Data-Binding)
Only provide VCL 64-bit for Win64
Is this a problem?
Does anyone know of an equivalent to FxCop/StyleCop for Delphi? I would really like to get the automatic checking of style, etc. into Continuous Integration.
There's Pascal Analyzer from Peganza: http://www.peganza.com/products_pal.htm
I don't know how the features compare to FxCop, since I haven't really used either one.
The closest I've seen is CodeHealer from SOCK software. We use it, and we have integrated it into our FinalBuilder build. It differs from FxCop in one important way: It analyzes the source code, rather than the produced executable. It also doesn't check quite as much as FxCop does. But I think it is the best thing which is available in this category for Delphi.
Delphi 2009 support isn't there just yet, but they say they're working on it.
Delphi Code Analyzer is another one that is open source.
The DGrok project started with something like FxCop some years ago. The parser and analysis parts are still available, read more at "DGrok 0.8.1: multithreading, default options, GPL" - The parser is a .Net project but
DGrok is a set of tools for parsing
Delphi source code and telling you
stuff about it. Read more about it on
the DGrok project page.
There is a new Delphi plugin for Sonar, which uses a Delphi grammar to run automatic tests over the source code.
I've heard of something called Delforex but haven't used it myself (yet)
Delforex is great for actually formatting the code. It does not do much more than that though. (we have/do use it).
I would second the votes for either Pascal Analyzer or Code Healer.
Vaccano
Doesn't Delphi output .net compatible IL code? I haven't used it in an age but I thought newer versions output .net assemblies.
If so then I would have thought FXcop would work and you could always add some of your own custom rules to it. Stylecop would not work but you could at least get FXCop running.
Are there any support tools like coderush or resharper for F#?
Preview version of FSharpRefactor released in Visual Studio Gallery.
http://visualstudiogallery.msdn.microsoft.com/339cbae9-911d-4f99-9033-3c3564676f45
http://www.youtube.com/watch?v=T6-YjUULNCA/
F# Refactor open source project on CodePlex (Apache license).
Take a look at the open-source Visual F# Power Tools project. They've got a rename refactoring, some code generation stuff (eg. record stub generation), graying out of unused declarations, as well as some other things. They're moving pretty fast at the moment, with lots of new features getting added all the time.
There's an effort to support F# in ReSharper via an external plug-in (itself written in F#). You can find preliminary info here.
FSharpRefactor 0.1 (Preview version) Released on the Visual Studio Gallery.
http://visualstudiogallery.msdn.microsoft.com/339cbae9-911d-4f99-9033-3c3564676f45?SRC=Home
Not yet, as far as I know. I was also looking for something similar to no success. I suspect as soon as F# hits VS2010 as its integral part, or even a bit earlier, such tools will eventually emerge.
As far as ReSharper is concerned, you may want to drop JetBrains a quick email, it would be interesting to know whether these guys have any plans regarding F#.
Since the push in f# is towards light mode the reformatting possible is likely to be both limited, and hard to implement.
Normally reformatting takes the structural information and uses that to create the textual position. In the case of #light the textual position (of indenting at least) is the structure. As such any reformatting would be at best to sort inter symbol spacing, hardly onerous to do yourself.
I would therefore not expect a commercial product for it at least until the 'proper' integration with the IDE (I do not consider the current CTP proper in this regard since several outstanding bugs with it exist which will not be fixed in 2008)
CodeRush is working in F# editor. At least some code assistance and code templates. But code templates are not defined yet (you have to create your own).