Can the Ruby language be used to create an entire new mobile operating system or desktop operating system i.e. can it be used in system programming?
Well there are a few operating systems out there right now which use higher-level languages than C. Basically the ruby interpreter itself would need to be written in something low-level, and there would need to be some boot-loading code that loaded a fully-functional ruby interpreter into memory as a standalone kernel. Once the ruby interpreter is bootstrapped and running in kernel-mode (or one of the inner rings), there would be nothing stopping you from builing a whole OS on top of it.
Unfortunately, it would likely be very slow. Garbage collection for every OS function would probably be rather noticeable. The ruby interpreter would be responsible for basic things like task scheduling and the network stack, which using a garbage-collecting framework would slow things down considerably. To work around this, odds are good that the "performance critical" pieces would still be written in C.
So yes, technically speaking this is possible. But no one in their right mind would try it (queue crazy person in 3... 2...)
For all practical purposes: No.
While the language itself is not suited for such a task, it is imaginable (in some other universe ;-) that there a Ruby run-time developed with such a goal in mind.
The only "high level" -- yes, the quotes are there for a reason, I don't consider C very "high level" these days -- language I know of designed for Systems Programming is BitC. (Which is quite unlike Ruby.)
Happy coding.
Edit: Here is a list of "Lisp-based OSes". While not Ruby, the dynamically-typed/garbage-collected nature of (many) Lisp implementations makes for a favorable comparison: if those crazy Lispers can do/attempt it, then so can some Ruby fanatic ... or at least they can wish for it ;-) There is even a link to an OCaml OS on the list...
No, not directly
In the same way that Rails is built on top of Ruby, Ruby is built on top of the services that lower layers .. the real OS .. provide.
I suppose one could subset Ruby until it functionally resembled C and then build an OS out of that, but it wouldn't be worth it. Sure, it would have a nice if .. end but C syntax is perfectly usable and we already have C language systems. Also, operating systems don't handle character data very much, so all of the Ruby features to manipulate it wouldn't be as valuable in a kernel.
If we were starting from scratch today we might actually try (as various experimental projects have) to use garbage collected memory allocation in a kernel but we already have OS kernels.
People are making investments at the higher layers rather than redoing work already done. After all, with all the upper level software to run these days, a new kernel would need to present a compatible interface and the question would then be asked "why not just run the nice kernels we already have?".
Now, the application API for a mobile OS could indeed be done for Ruby. So, just as Android apps are written in Java, RubyPhone apps could be written in Ruby. But Ruby might not be the best possible starting point for a rich application platform. Its development so far has been oriented to server-side problems. There exist various graphical interface gems but I don't think they are widely used.
basically yes, but with a big disclamer .. which is basically Chris' answer but a different spin on it. Since for kernel performance it would kinda suck to use ruby, you'd probably want to build around a linux-ish kernel and just not load any of the rest of the operating system. This is basically what Android does: the kernel is a fork from Linux (and is maintained close to linux), the console is a webkit screen, and the interpreter is Java with some Android specific libraries. IE, Android is Java masquerading as an OS, .. you could do about the same thing with Ruby instead of Java and only a smallish hit to performance from java
While building a whole OS from scratch in Ruby seems like
a multi-billion project (think of all the drivers), a
linux kernel module that runs simple ruby scripts does
make sense for me - even it was only for prototyping
new linux drivers.
Related
Programming languages are platform independent, so why is it that we can't write a program that will run on both a PC and a Mac?
I want to develop a software and I'm on a mac, but I want it to run on a PC also, is it possible to develop such a software without having to require the user to download a special program that will make my program compatible with their computer?
The problem with this is that most software is dependent on the OS to handle some tasks. Yes, most programming languages are compatible with many platforms, but the OS provides a lot of support. When software uses the OS, it is sometimes called making a system call. If you want here is some more information.
Theoretically if you write your program in a 'high level language' it should be portable between two operating systems.
Practically however, the differences start from the very beginning - the API of choice, which works on one and does not on another(Such as, Mac's BSD API is incompatible with Win32 API) and boils down to the very last, which is, executable format, linker and loader. Each operating system has its own quirks.
Then comes the difference between the underlying architecture. Previously Macs ran on PowerPC architecture and Motorola architectures, while PCs used Intel. Since Macs have switched to Intel, there have been attempts at making cross platform executables inside Apple. Most attempts have failed.
There is however a way around your problem. You can use a very high level language such as Python to code and then distribute your python code to your PC friends.(But remember remember, you need a Python interpreter in your PC friends' computers for your program to run). I have successfully ported Python programs from Mac to PC with 0 code changes, and sometimes requiring only 2-4% code changes.
Simple answer: because language per se is not enough to make an application cross-platform. Also the framework it uses must be cross-platform too, frameworks are required for everything: handling data, displaying things, communicate with the hardware, multi threading, etc
This can usually be done:
by choosing a complete solution like Java, which will actually run on both platforms seamlessly and even with the same binary
by using C/C++ and cross platform libraries so that the same program can be compiled for both platforms (keep in mind that you can't distribute the real same binary, you need to compile two in any case)
by writing the logic of your program just using standard libraries and a standard language and then attach whatever you need for a specific platform just to build two different libraries. Of course you will have to wrap as much as you need so that the cross-platform part of your program doesn't know it
Mind that developing cross-platform applications which are not trivial examples like a game (for which there are plenty of cross-platform APIs) without using a complete solution like Java is not an easy task at all. Especially because most of the GUI you can build are strictly platform specific and relies on their own frameworks.
If you want an application to run "anywhere" your best option is a JIT type language which means that it compiles as it runs (Just In Time) for the platform that it's on. Really the language that stands out in my mind is Java (there's others and personally I don't like java). However, it's not quite that simple. For example a Window on a Mac computer has pieces and functions that a Window on a PC doesn't have and vice versa. And other operating systems don't even have windows or anything equivilant yet still run Java like Android or iOS for example or countless Linux Distros. And that's just a very basic example it gets MUCH MUCH harrier. Really the best way to build an application that can be used by anyone on just about any device is going web based.
The lesson is that if it was that simple a lot of people wouldn't have jobs and it never will be that simple, things will always progress and change and not everyone is going to want to do the same thing with their OS as someone else. There's a million ways to skin a cat and there's many more ways to implement something in an OS.
Yes, it is possible. But it is quite tricky. You need to:
Use a cross platform language (this is the easy part, many languages run on different plaftforms)
Avoid using any platform-specific features (usually not too hard, but needs testing)
Ensure you have cross platform libraries for all your dependencies (hard!)
Because of the library issue in particular, there are very few options that work across platforms. Your best options are probably:
A JVM language (like Java, Scala or Clojure) - because the JVM abstracts away from platform specific features, pure Java applications and libraries will run on any platform. Java probably has the best ecosystem of cross platform libraries and tools as a result.
JavaScript - quite a good option if you don't mind running in a browser. There are lots of quirks to deal with, but JavaScript is one of the best cross-platform options because of it's ubiquity.
Could anyone here tell me the difference between the Ruby gems rubysdl and ruby-sdl-ffi, like speed variances? If so, which would you prefer? I'm wondering for the sake of my gem that I'm writing, Rubydraw (located here).
Thanks in advance!
I am the author of ruby-sdl-ffi. This question was brought to my attention today, so I am answering for the benefit of anyone who is still curious.
The main difference is that ruby-sdl-ffi is pure Ruby code that accesses SDL (and related libraries) via FFI (foreign function interface), whereas rubysdl is an extension written in C that links to SDL (and related libraries). There are pros and cons to each approach. (Obviously, I feel that FFI is the better approach, or I would not have bothered to write ruby-sdl-ffi.)
Both libraries offer similar feature sets, although there are some differences (noted below). They can both do 2D games with images, sounds/music, and user input from keyboard, mouse, and/or joystick/gamepad. They can also both be used with OpenGL (via ruby-opengl or ffi-opengl) to create hardware-accelerated 3D games. They can both be used on Windows, MacOS X, and Linux (and perhaps other platforms), although rubysdl only works on MacOS X if you use a special Ruby interpreter wrapper called "rsdl".
I have not run any serious benchmarks, so I can't provide any definitive data about raw performance. My general impression is that rubysdl might have a slight performance advantage, but they are close enough that performance isn't the main factor when deciding between the two libraries.
Here is how I would summarize the pros and cons of the two libraries:
ruby-sdl-ffi
Easier for users to install the gem. It does not need to be compiled, so users don't need to install a C compiler or toolchain.
Works with MRI (the "usual" Ruby interpreter), JRuby, and probably Rubinius.
No special interpreter is required on MacOS X. However, the MacOS X support may need to be updated to get it working totally right on the latest versions of MacOS X. (Apple keeps changing things.)
Lower-level API, more closely mirrors the C libraries. This may be good or bad depending on your perspective.
Currently has bindings for SDL, SDL_gfx, SDL_image, SDL_mixer, and SDL_ttf libraries. (Compared to rubysdl, it adds SDL_gfx but lacks SGE and SMPEG.) Adding bindings for other libraries is quite easy.
Not actively developed or maintained anymore. I don't have the time or interest anymore, but someone is welcome to take over, and I can provide guidance.
Somewhat experimental, and has some rough edges.
rubysdl
More mature and polished, has withstood the test of time.
Better support for Japanese text input and rendering.
Higher-level, more abstract API.
Binds SDL, SGE, SMPEG, SDL_image, SDL_mixer, and SDL_ttf libraries.
Requires users to have a C compiler to install the gem. This can be quite a headache on Windows and MacOS X.
Requires MacOS X users to run your game using the special "rsdl" Ruby interpreter. Thus, to my knowledge, it will not work with JRuby or Rubinius on MacOS X.
Does not seem to be actively developed or maintained anymore either.
It’s the first time I submit a question in this forum.
I’m posting a general question. I don’t have to develop an application for a specific purpose.
After a lot of “googling” I still haven’t found a language/runtime/script engine/virtual machine that match these 5 requirements:
memory allocation of variables/values or objects cleaned at run time
(e.g. a la C++ that use keyword delete or free in C )
language (and consequently the program) is a script or
pseudo-compiled a la byte code that should be portable on main
operating system (windows, linux, *bsd, solaris) & platform(32/64bit)
native use of multicore (engine/runtime)
no limit on the heap usage
library for network
The programming language for building application and that run on this engine is agnostic oriented (paradigm is not important).
I hope that this post won’t stir up a Holy-War but I'd like to put focus on engine behavior during program execution.
Sorry for my bad english.
Luke
I think Erlang might fit your requirement:
most data is either allocated in local scopes and therefore immediately deleted after use or contained in a library-powered permanent storage like ETS, DETS or Mnesia. There is Garbage Collection, though, but the paradigm of the language makes the need for it not as important.
the Erlang compiler compiles the source code to the BEAM virtual machine byte code, which, unlike Java is register-based and thus much faster. The VM is available for:
Solaris (including 64 bit)
BSD
Linux
OSX
TRU64
Windows NT/2000/2003/XP/Vista/7
VxWorks
Erlang has been designed for distributed systems, concurrency and reliability from day one
Erlang's Heap grows with your demand for it, it's initially limited and expanded automatically (there are numerous tweaks you can use to configure this on a per-VM-basis)
Erlang comes from a networking background and provides tons of libraries from IP to higher-level protocols
Is there, by chance, an emerging Haskell UI framework for Windows?
I recently took up looking over the language, and from what I see, it would be for great little "one-off" applications (elaborate scripts).
However, without a good UI framework I can't see it getting in under the smoke and mirrors of the more obvious contenders.
I've read that there are many frameworks, but none are full-featured.
I'm just wondering if this is something that's on the rise, or is it simply too difficult to get enough developers going in the same direction with one?
The two main frameworks are wxHaskell and Gtk2Hs. Both of these have been used for real work. From what I know my preference would be Gtk2Hs because it handles resources properly (i.e. uses the GC). wxHaskell requires the programmer to release widgets once they are no longer required, so you can get all the classic memory leaks and stale pointer screws with it.
The problem with both is that everything is in the IO monad. This reflects the fact that they are comparatively thin wrappers around existing GUI libraries for imperative languages. Of course this means you are no worse off than you would be writing a GUI in an imperative language, but you are hardly much better off either.
There are some interesting experimental libraries to be found on Hackage, including Grapefruit and Conal Elliott's "Tangible Values" ideas in GuiTV. Both of these try for a more declarative approach.
(Disclaimer: I am the wxHaskell maintainer)
Both wxHaskell and Gtk2Hs are more or less complete. That's to say, both wrap a great deal of the functionality provided by their underlying libraries. They also both, as mentioned earlier, require a rather 'imperative' style of programming in the IO monad.
There have been many discussions on the relative merits of each. I would say that wxHaskell is the easier of the two to get working, especially on Windows, as it can be installed via cabal (see http://www.haskell.org/haskellwiki/WxHaskell/Install#On_Windows)
The FRP frameworks (Grapefruit and others) provide a more 'functional' style of programming, at the cost of having much reduced widget coverage. I have the feeling that this is still an open research area, and not really ready for 'prime time'.
In practice, I've never had resource management issues with wxHaskell, although I agree that it's possible, and is an area handled better by Gtk2Hs, which uses reference counting in the underlying library.
For completeness, I should also mention that a Qt binding (QtHaskell?) also exists - it is relatively young, but apparently reasonably complete.
I rather feel that the Haskell community, small as it is, would do well to fix on one GUI framework, but accept the difficulty of this (e.g. licensing, support for all OS platforms etc.).
Also you can use wxWidgets (i mean C++ library) with Haskell. Here is an example: https://bitbucket.org/afiskon/hs-a-star-gui/src Such approach has some advantages over wxHaskell: 1. You can use UI generators (Code::Blocks, wxFormBuilder) 2. Your application takes less disk space 3. You can use all features of wxWidgets.
It should also be noted, that last version of wxHaskell uses wxWidgets 2.9, which probably will never be ported to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=613431
Every time I see a discussion on software development, always someone suggests or exalts the qualities of Smalltalk, be it the beautiful language constructs or the better implementation of basically everything.
So I was curious, is anybody developing in Smalltalk? can Smalltalk actually be used to develop software on the Mac? Or what is the target platform for Smalltalk? What is the poster child for this apparently fantastic but unpopular language?
Smalltalk isn't really used for GUI application development on the Mac in any major way. The only distribution that could produce native apps was Ambrai Smalltalk, and that died in beta AFAIK. Squeak is the most popular Smalltalk variant nowadays, but you will be torn limb from limb if you release a Mac OS X app that looks like Squeak. It's worth checking out if you're interested in learning the language (which is still unique in a lot of ways), but you're probably not going to be developing OS X apps with it.
If you would like something similar, check out MacRuby. Ruby is as close as you can get to Smalltalk without actually being Smalltalk — total object orientation, dynamic, 100% message-based, heavy use of blocks, etc. MacRuby is an implementation being developed by Apple specifically for making OS X applications.
Mac OS X's native Objective-C is also heavily Smalltalk-inspired (it's basically a big chunk of Smalltalk's object system and syntax bolted onto C), but owing to its extreme C compatibility, it falls a little further from the tree.
Take a look at fscript, which is essentially a smalltalk-like language for Objective C.
Luis: do you want to do desktop application for Mac ? or you want to program in Mac? If you want to do a web application for example, you can perfectly use Squeak or Pharo. If you want to do native mac applications, you should see the Mars project for Squeak:
http://smallworks.com.ar/productos/Mars
As an example, most of the Pharo users and developers are under Mac.
http://www.pharo-project.org/home
download and try it at least for a couple of hours!
I still believe that Squeak is well worth investigating, if only to broaden your mind a little. As for the poster child for Smalltalk, it's probably Seaside.
Squeak isn't its UI. You can configure Morphic heavily (look at how similar Pharo's is to OSX, for instance). Or you can just use native widgets with wxSqueak.
This deserves some attention:
"Objective-Smalltalk was created specifically to solve practical problems that have been encountered in 25 years of Objective-C and Smalltalk use, but with a theoretical framework that solves many of these problems elegantly and minimally, rather than by bolting on special feature after special feature."
http://objective.st/