Related
I am working on a new language, targeted for web development, embeding into applications, distributed applications, high-reliability software (but this is for distant future).
Also, it's target to reduce development expenses in long term - more time to write safer code and less support later. And finally, it enforces many things that real teams have to enforce - like one crossplatform IDE, one codestyle, one web framework.
In short, the key syntax/language features are:
Open source, non-restrictive licensing. Surely crossplatform.
Tastes like C++ but simpler, Pythonic syntax with strict & static type checking. Easier to learn, no multiple inheritance and other things which nobody know anyway :-)
LLVM bytecode/compilation backend gives near-C speed.
Is has both garbage collection & explicit object destruction.
Real OS threads, native support of multicore computers. Multithreading is part of language, not a library.
Types have the same width on any platform. int(32), long(64) e.t.c
Built in post and preconditions, asserts, tiny unit tests. You write a method - you can write all these things in 1 place, so you have related things in one place. If you worry that your class sourcecode will be bloated with this - it's IDEs work to hide what you don't need now.
Java-like exception handling (i.e. you have to handle all exceptions)
I guess I'll leave web & cluster features for now...
What you think? Are there any existing similar languages which I missed?
To summarize: You language has no real selling points. It just does what a dozen other languages already did, with syntax and semantics just slightly off, depending on where the programmer comes from. This may be a good thing, as it makes the language easier to adapt, but you also have to convince people to trouble to switch. All this stuff has to be built and debugged and documented again, tools have to be programmed, people have to learn it and convince their pointy-haired bosses to use it, etc. "So it's language X with a few features from Y and nicer syntax? But it won't make my application's code 15% shorter and cleaner, it won't free me from boilerplate X, etc - and it won't work with my IDE." The last one is important. Tools matter. If there are no good tools for a language, few people will shy away, rightfully so.
And finally, it enforces many things that real teams have to enforce - like one crossplatform IDE, one codestyle, one web framework.
Sounds like a downside! How does the language "enforce one X"? How do you convince programmers this coding style is the one true style? Why shouldn't somebody go and replace the dog slow, hardly maintained, severly limited IDE you "enforce" with something better? How could one web framework possibly fit all applications? Programmers rarely like to be forced into X, and they are sometimes right.
Also, you language will have to talk to others. So you have ready-made standard solutions for multithreading and web development in mind? Maybe you should start with a FFI instead. Python can use extensions written in C or C++, use dynamic libraries through ctypes, and with Cython it's amazingly simple to wrap any given C library with a Python interface. Do you have any idea how many important libraries are written in C? Unless your language can use these, people can hardly get (real-world) stuff done with it. Just think of GUI. Most mayor GUI toolkits are C or C++. And Java has hundreds of libraries (the other JVM languages profit much from Java interop) for many many purposes.
Finally, on performance: LLVM can give you native code generation, which is a huge plus (performance-wise, but also because the result is standalone), but the LLVM optimizers are limited, too. Don't expect it to beat C. Especially not hand-tuned C compiled via icc on Intel CPUs ;)
"Are there any existing similar
languages which I missed?"
D? Compared to your features:
The compiler has a dual license - GPL and Artistic
See example code here.
LDC targets LLVM. Support for D version 2 is under development.
Built-in garbage collection or explicit memory management.
core.thread
Types
Unit tests / Pre and Post Contracts
try/catch/finally exception handling plus scope guarantees
Responding to a few of your points individually (I've omitted what I consider either unimportant or good):
targeted for web development
Most people use php. Not because it's the best language available, that's for sure.
embeding into applications
Lua.
distributed applications, high-reliability software (but this is for distant future).
Have you carefully studied Erlang, both its design and its reference implementation?
it enforces many things that real teams have to enforce - like one crossplatform IDE, one codestyle, one web framework.
If your language becomes successful, people will make other IDEs, other code styles, other web frameworks.
Multithreading is part of language, not a library.
Really good languages for multithreading forbid side effects inside threads. Yes, in practice that pretty much means Erlang only.
Types have the same width on any platform. int(32), long(64) e.t.c
Sigh... There's only one reasonable width for integers outside of machine-level languages like C: infinite.
Designing your own language will undoubtedly teach you someting. But designing a good language is like designing a good cryptosystem: lots of amateurs try, but it takes an expert to do it well.
I suggest you read some of Norman Ramsey's answers here on programming language design, starting with this thread.
Given your interest in distributed applications, knowing Erlang is a must. As for sequential programming, the minimum is one imperative language and one functional language (ideally both Lisp/Scheme and Haskell, but F# is a good start). I also recommend knowing at least one high-level language that doesn't have objects, just so you understand that not having objects can often make the programmer's life easier (because objects are complex).
As for what could drive other people to learn your language... Good tools/libraries/frameworks can't hurt (FORTRAN, php), and a big company setting the example can't hurt (Java, C#). Good design doesn't seem to be much of a factor (a ha-ha-only-serious joke has it that what makes a language successful is using {braces} to delimit blocks: C, C++, Java, C#, php)...
What you've given us is a list of features, with no coherent philosophy, or explanation as to how they will work together. None of the features are unique. At best, you're offering incremental improvements over what's already there. I'd expect there's already languages kicking around with what you've said, it's just that they're still fairly obscure, because they didn't make it.
Languages have inertia. People have to learn new languages, and sometimes new tools. They need incentive to do so, and 20% improvement in a few features doesn't cut it.
What you need, at a minimum, is a killer app and a form of elevator pitch. (The "elevator pitch" is what you tell the higher-ups about your project when you're in the elevator with them, in current US business parlance.) You need to have your language be obviously worth learning for some purpose, and you need to be able to tell people why it's worth learning before they think "just another language by somebody who wanted to write a language" and go away.
You need to form a language community. That community needs to have some localization at first: people who work in X big company, people who want to do Y, whatever. Decide on what that community is likely to be, and come up with one big reason to switch and some reasons to believe that your language can deliver what it promises.
No.
Every buzzword you have included in your feature list is an enormous amount of work to be spec'd, implemented, documented, and tested.
How many people will be actively developing the language? I guess the web is full of failed programming language projects. (Same is true for non-mainstream OSes)
Have a look at what .Net/Visual Studio or Java/Eclipse have accomplished. That's 1000s of years of specification, development, tests, documentation, feedback, bug fixes, service packs.
During my last job I heard about somebody who wrote his own programming framework, because it was "better". The resulting program code (both in the framework and in the applications) is certainly unmaintainable once the original programmer quits, or is "hit by a bus", as the saying goes.
As the list sounds like Java++ or Mono++, you'd probably be more successful in engaging in an existing project, even if it won't have your name tag on it.
Perhaps you missed one key term. Performance.
In any case, unless this new language has some really out-of-this-world features(ex: 100% increase in performance over other web development languages), I think it will be yet another fish in the pond.
Currently I'm responsible for maintaining a framework developed/owned by my company. It's a nightmare. Unless there is a mainstream community, working on this full time, it's really an elephant. I do not appreciate my company's decision to develop its own framework(because it's supposed to be "faster") day 'n night.
The language tastes good in my opinion, I don't want use java for a simple website but I would like to have types and things like that. ASP .NET is a problem because of licensing and I can't afford those licenses for a single website... Also features looks good
Remember a lot of operator overloading: I think is the biggest thing that PHP is actually missing. It allows classes to behave much more like basic types :)
When you have something to test I'll love to help you with it! Thanks
Well, if you have to reinvent the wheel, you can go for it :)
I am not going to give you any examples of languages or language features, but I will give you one advice instead:
Supporting framework is what is the most important thing. People will tend to love it or hate it, depending on how easy is to write good code that get job done. Therefore, please do usability test before releasing it. I mean ask several people how they will do certain task and create API accordingly. Then test beta API on other coders and listen carefully to their comments.
Regards and good luck :)
There's always space for another programming language. Apart from getting the design right, I think the biggest problem is coming across as just another wannabe language. So you may want to look at your marketing, you need a big sponsor who can integrate your language into their products, or you need to generate a buzz around it, easiest way is astroturfing. Good luck.
http://en.wikipedia.org/wiki/List_of_programming_languages
NB the names G and G++ aren't taken. Oh and watch out for the patent trolls.
Edit
Oops G / G++ are taken... still there are plenty more letters left.
This sounds more like a "systems" language rather than a "web development language". The major languages in this category (other than C++/C) are D and Go.
My advice to you would be to not start from scratch but examine the possibility of creating tools or libraries for those languages, and seeing just how far you can push them.
Using the right language for the job is the key - this is the comment I read in SO and I also belive thats the right thing to do. Because of this we ended up using different languages for different parts of the project - like perl, VBA(Excel Macros), C# etc. We have three to four languages currently in use inside the project. Using the right language for the job has made it immensly more easy to do automate a job, but of late people are complaining that any new person who has to take over the project will have to learn so many different languages to get started. Also it is difficult to find such kind of person. Please note that this is a one to two person working on the project maximum at a given point of time. I would like to know if the method we are following is right or should we converge to single language and try to use it across all the job even though another language might be better suited for it. Your experenece related to this would also help.
Languages used and their purpose:
Perl - Processing large text file(log files)
C# with Silverlight for web based reporting.
LabVIEW for automation
Excel macros for processing data in excel sheets, generating graphs and exporting to powerpoint.
I'd say you are doing it right. Almost all the projects I've ever worked on have used multiple languages, without any problems. I think you may be overestimating the difficulty people have picking up new languages, particularly if they all use the same paradigm. If your project were using Haskell, Smalltalk, C++ and assembler, you might have difficulties, I must admit :-)
Using a variety languages vs maintainability is simply another design decision with cost-vs-benefits trade-offs that, like any design decision, need to considered carefully. While I like using the "absolute best" tool for the task (whatever "absolute best" means), I wouldn't necessarily use it without considering other factors such as:
do we have sufficient skill and experience to implement successfully
will we be able to find the necessary resources to maintain it
do we already use the language/tech in our system
does the increase in complexity to the overall system (e.g. integration issues, the impact on build automation) outweigh the benefits of using the "absolute best" language
is there another language that we already use and have experience in that is usable in lieu of the "absolute best" language
I worked a system with around a dozen engineers that used C++, Java, SQL, TCL, C, shell scripts, and just a touch of Perl. I was proud that we used the "best language" where they made sense, but, in one case, using the "best language" (TCL) was a mistake - not because it was TCL - but rather because we failed to observe the full costs-vs-benefits of the choice:*
we had only 1 engineer deeply familiar with TCL - the original engineer who refused to use anything but TCL for a particular target component - and then that engineer left the project
this target component was the only part of the system to use TCL and it was small relative to the other components in the system
the component could have been also implemented in another language we already used that we had plenty of experience in (C or C++) with some extra effort
the component appeared deceptively simple, but in reality had subtle corner cases that bit us in production (not something we could have known then, but always something to consider as a possibility later)
we had to implement special changes to the nightly build because the TCL compiler (yes, we compiled the TCL code into an executable) wouldn't work unless it could first throw its logo up on the screen - a screen which wasn't available during a cron-initiated automated nightly build. (We resorted to using xvfb to satisfy it.)
when bugs turned up, we had difficult time finding engineers who wanted to work on it
when problems with this component cropped up only after sustained load in the field, we lacked the experience and deep understanding of the TCL execution engine to easily debug it in the field
finally, the maintenance and sustainment team, which is a much smaller team with fewer resources than the main development team, had one more language that they needed training and experience in just to support this relatively small component
Although there were a number of things we could have done to head-off some of the issues we hit down the road (e.g. put more emphasis on getting TCL experience earlier, running better tests to detect the issues earlier, etc), my point is that the overall cost-vs-benefit didn't justify using TCL to code that single component. Again, it was not a mistake to use TCL because it was TCL (TCL is a fine language), but rather it was a mistake because we failed to give full consideration to the cost-vs-benefits.
As a Software Engineer it's your job to learn new languages if you need to. I would say you should go with the right tool for the job.
It's like sweeping the floor with an octopus. Yeah, it gets the job done... kind of... but it's probably not the best tool for the job. You're better off using a mop.
Another option is to create positions geared towards working in specific languages. So you can have a C# developer, a Perl developer, and a VBA developer who will only work with that language. It's a bit more overhead, but it is a workable solution.
Any modern software project of any scope -- even if it's a one-person job -- requires more than one language. For instance, a web project usually requires Javascript, a backend language, and a DB query language (though any of these might be created by the backend language). That said, there's a threshold that is easily reached, and then it would be very hard to find new developers to take over projects. What's the limit? Three languages? Four? Let's say: five is too many, but one would be too few for any reasonably complex project.
Using the right language for the right job is definitely appropriate - I am mainly a web programmer, and I need to know server-side programming (Rails, PHP + others), SQL, Javascript, jQuery, HTML & CSS (not programming languages strictly, but complex things I need to know) - it would be impossible for me to do all of that in a single language or technology.
If you have a team of smart developers, picking up new languages will not be a problem for them. In fact they probably will be eager to do so. Just make sure they are given adequate time (and mentoring) to learn the new language.
Sure, there will be a learning curve to implementing production code if there is a new language to learn, but you will have a stronger team member for it.
If you have developers in your teams who strongly resist learning new languages, unless there is a very good reason (e.g they are justifiably adamant that they are being asked to used a different language when it is not appropriate to do so) - then they are not the sort of developers I'd want in my teams.
And don't bother trying to hire people who know all the languages you use. Hire smart programmers (who probably know at least one language you use) - they should pick up the other languages just fine.
I would be of the opinion, that if I a programmer on my team wanted to introduce a second (or third) language into a project, that there better be VERY VERY good reason to do so; as a project manager I would need to be convinced that the cost of doing so, more than offset the problems. And it would take a lot of convincing.
Splitting up project into multiple languages makes it very expensive to hire the right person(s) to take over that project when it needs maintenance. For small and medium shops it could be a huge obstacle.
Edit: I am not talking about using javascript and c# on the same project, I am talking about using C# for most of the code, F# for a few parts and then VB or C++ for others - there would need to be a compelling reason.
KISS: 'Keep it simple stupid' is a good axiom to follow in most cases.
EDIT: I am not completely opposed to adding languages, but the burden of proof is on the person to who wants to do it. KISS (to me) applies to not only getting the project/product done and shipped, but also must take into account the lifetime maint. and support requirements. Lots of languages come and go, and programmers are attracted to new languages like a moth to a light. Most projects I have worked on, I still oversee and/or support 5 or 10 years later - last thing I want to see is some long forgotten and/or orphaned language responsible for some key part of an application I need to support.
My experience using C++ and Lua was that I wrote more glue than actual operational code and for dubious benefit.
I'd start by saying the issue is whether you are using the right paradigm for the job?
Suppose you know how to do object oriented programming in C#. I don't think the leap to Java is all that great . Although you'd have to familiarize yourself with libraries and syntax, the idea is pretty similar.
If you have procedural parts to your project, such as parsing files and various data transformations, your Perl/Excel Macros seem pretty similar.
But to address your issues, I'd say above all, you'll need clarity in code. Since your staff are using several languages, they won't be familiar with all languages to an equal degree. So make sure of this:
1) Syntactic sugar is explained in comments. Sugars are pretty language specific and may not be obvious to a new reader. For instance, in VBA I seem to remember there are default properties, so that TextBox1 = "Hello" is what you'd write instead of TextBox1.Text = "Hello". This can be confusing. Also, things like LINQ statements can have un-obvious meanings. So make sure people have comments to read.
2) Where two components from different languages have to work together, make excruciatingly specific details about how that happens. For instance, I once had to write a C component to be called from Excel VBA. There's quote a few steps and potential errors in doing this, especially as far as compiler flags. Make sure both sides know how their side of the interaction occurs.
Finally, as far as hiring people goes, I think you have to find people who aren't married to a specific language. To put it vaguely, hire an intelligent person who sees business issues, not code. He'll learn the lingo soon enough.
What are some situations where languages should be mixed?
I'm not talking about using ASP.NET with C# and HTML or an application written in C accessing a SQL database through SQL queries. I'm talking about things like mixing C++ with Fortran or Ada with Haskell etc. for example.
[EDIT]
First of all: thank you for all your answers.
When I asked this question I had in mind that you always read "every language has its special purpose".
In general, you can get almost everything done in any language by using special libraries. But, if you are interested in learning different languages, why not take the programming language that serves your purpose best instead of a library that solves a problem your language wasn't originally designed for?
For example, in video games we use different languages for different purpose :
Application (Game) code : have to be fast, organized and most of the time cross-platform (at least win, MacOS is to be envisaged), often on constraint-heavy platforms (consoles), so C++ (and sometimes C and asm) is used.
Development Tools : level design tools generates data that the game code will play with. Those kind of tool don't need to run on the target platform (but if you can it's easier to debug) so often they are made with fast-development languages such as C#, Python, etc.
Script system : some parts of the games will have to be tweaked by the designers, using variables or scripts. It's really easier and cheap to embed a scripting language instead of writing one so Lua or other similar scripting languages are often used.
Web application : sometimes a game will require to provide some data online, most often in a database accessed with SQL. The web application then is written in a language that might be C#, Ruby(R.O.R.), Python, PHP or anything else that is good for the job. As it's about the web, you then have to use HTML/Javascript too.
etc...
In my game I use HTML/Javascript for GUI too.
[EDIT]
To answer your edit : the language you know the best is not always the most efficient tool for the work. That's why for example I use C++ for my home-made game because I know it best (I could use a lot of other languages as the targets are Win/Mac/Linux, not consoles) but I use Python for everything related to build process, file manipulation etc. I don't know Python in depth but it's fare easier to do quick file manipulation with it than with C++. I wouldn't use C++ for web application for obvious reasons.
In the end, you use what is efficient for the job. That's what you learn by working in real world constraints, with money, time and quality in mind.
Well, the most obvious (and the most common) situation would be when you use some high level language to make most of your program, reaping the benefits of fast development and robustness, while using some lower level language like C or even assembly to gain speed where it is important.
Also, many times it is necessary to interface with other software written in some other language. A good example here are APIs exposed by the operating system - they're usually written with C in mind (though I remember some old MacOS versions using Pascal). If you don't have a native binding for your language-compiler infrastructure, you have to write some interface code to "glue" your program with "the other side".
There are also some domain-specific languages that are tuned specifically to efficiently express some type of computation. You usually don't write your entire program in them, just some parts where it is the appropriate tool. Prolog is a good example.
Last but not least, you sometimes have heaps of old and tested code written in another language at hand, which you could benefit from using. Instead of reinventing the wheel in a new and better language, you may simply want to interface it to your new program. This is probably the most usual (if not the only) case when languages geared for similar uses are mixed together (was that C++ and Fortran you mentioned?).
Generally, different languages have different strengths and weaknesses. You should try to use the appropriate tool for the job at hand. If the benefits from expressing some parts of the program in a different language are greater than the problems this introduces, then it's best to go for it.
I know in your question you sort of ruled this out, but different languages are used for different domains.
Right now I am working on a data visualizer, the data is in a database so of course there is some SQL, but that hardly counts because it's small and required frequently. The data is turned into a series of graphs, I'm using R, which is like MATLAB but open source. It is a unique statistical language with some advanced plotting features.
A data visualizer isn't just a graph generator, so there needs to be a way to browse and navigate this pile of image files. We opted to use html with embedded javascript to build an offline "application" that can be easily distributed. It's offline in the sense that it is self contained, that html is carefully generated and the js inside it is carefully crafted to allow the user to browse thousands of images sorting or filtering by a number of criteria.
How do you carefully craft javascript and html based on a database structure that changes as the rest of my team makes progress? They are made by a perl program (single pass script really) that reads into the db for some structure and key information, and then outputs over 300 kilobytes of html/js. It's not entirely trivial html either, imagemaps that are carefully aligned with the R plots and some onclick() javascript allow the user to actually interact with a plain image plot so this whole thing feels like a real data browser/visualizer application.
That's four 'languages', five if you count SQL, just to make a single end product.
I dont think doing this in a single language would be a good choice, because we are exploiting the capabilities of a real web browser to give us a free GUI and frontend.
An excellent current example would be to write methods for creating XML documents in VB.NET, which has an "XML Literals" feature, which C# lacks. Since they're both .NET languages, there's no reason not to call one from the other:
Public Function GetEmployeeXml (ByVal salesTerritoryKey As Integer) As XElement
Using context As New AdventureWorksDW2008Entities
Dim x = <x>
<%= From s In context.DimSalesTerritory _
Where s.SalesTerritoryKey = salesTerritoryKey _
Select _
<SalesTerritory
region=<%= s.SalesTerritoryRegion %>
country=<%= s.SalesTerritoryCountry %>>
<%= From e in s.DimEmployee _
Select _
<Employee firstName=<%= e.FirstName %> lastName=<%= e.LastName %>>
<%= From sale in e.FactResellerSales _
Select _
<Sale
orderNumber=<%= sale.SalesOrderNumber %>
price=<%= sale.ExtendedAmount %>/> %>
</Employee> %>
</SalesTerritory> %>
</x>
Return x
End Using
End Function
The biggest reason you would mix langauges is because one language has advantages in certain areas, where another has advantages in another. So, you try to harness the capabilities of both by throwing them together. A common example is using C and ASM, because C is more abstract and makes it easy to do the more complex stuff in a program, however, you would want to use ASM to do base level stuff with hardware and the processor. So, they are often mixed, given the nature of C and its use in embedded systems.
Depending on what paradigm a language falls under, it has its pros and cons. For example, one might want to use the GUI capabilities of C# but use the efficient backtracking or Artificial Intelligence capabilities of Prolog (a language in the logical paradigm) to compute some details before displaying them.
A simplified example
Imagine trying to write a program that allows a user to play Chess against a computer.
(Potentially) I would:
1.) Create the visuals with Windows GUI Libraries.
2.) Calculate the possible moves using Prolog, and choose the best/most viable move.
3.) Retrieve the results from step 2 from Prolog in my C# code, and render the results.
4.) Allow for the gameplay and rapid development of visuals and UI in C# and rely on the Prolog for the calculations/backtracking
This most often happens when you already have code written in two or more different languages and you notice that it makes sense to combine the programs. Rewriting is expensive and takes time.
In the financial world you often have to keep programs alive (or replaced) 50 years. With technology replacement every 10 years, new contracts (mortgages, life insurance) are created in the newest language/environment. The four older ones just handle the monthly payments and changes to existing contracts. To know how the company is doing, you need to integrate data from all five systems.
I suppose keeping the old ones alive is cheaper than migrating each time to the newest technology. From a risk avoiding point of view it makes sense.
Web applications should probably not be mixed language for the developer. Smalltalk does just fine, with Gemstone for persistence and Seaside as web application framework. The multiple languages (javascript) can be hidden in the framework.
When 2 heads are better than one.
I've commonly seen games where flash was embedded with C# - with the AI and other heavy code running off a C++ DLL.
When forced to
Writing new code to augment a new system supported by an old framework
For instance in games (which are pretty hardcore applications) you usually have a very tight c++ engine that does all the heavy lifting and a scripting language (such as Lua) that's accessible and suited for making that collection of special cases that we call 'game' happen.
People here have most of the reason. I'll just have this one:
There is also the case of graceful degradation. For instance I am working on a legacy intranet, and we're changing little by little from a language to another so at this point we have different languages in the same system.
Device Programming - typically you would want to program the UI with the OS's native UI language (Java for Android for example) but would need to program the device drivers with something that gets more into the low level (like C).
Me and my friend are in the first stages of creating a domain-specific language designed for game programming, for his thesis paper.
The language will be fairly low-level, it will have a C-like syntax, optional garbage collection, and will be geared towards systems that have little memory or processing power (ie. Nintendo DS), but should be powerful enough to facilitate PC development easily.
It won't be a scripting language, but a compiled one, but as we don't want to spend months writing a normal compiler, the first implementation will basically be a LanguageName-to-C translator, with TCC or GCC as the end compiler.
Now, I have a question for all you game programmers out there:
What would you like to see in such a language? What features, implementation- and syntax-wise, would be best for it? What to avoid?
Edit:
Some things we already thought up:
state-based objects - an object can exist in one of it's states (or sub-states)
events and functions - events don't have to exist to be called, and can bubble up
limited dynamic allocation and pointer support - we want it to be as safe as possible
support for object compositing (Hero is composed (dynamically) of Actor, Hurtable, Steerable, etc.)
"resources" in states, loaded and unloaded automatically at beginning/end of state (for example, an OpenGL texture object is a resource)
basic support for localization and serialization
a syntax that is quickly parsable
we want to make the language as consistent as possible: everything is passed as value, every declaration has predictable syntax (eg. function retType name(type arg) is (qualifier, list) { }; no const, static, public qualifiers anywhere except in the qualifier list), etc.
Something to make concurrent programming easier. A blend of Erlang and C++ perhaps. I've been thinking about this on and off ever since the Cell processor was announced but it would take a serious chunk of R&D time to develop it and solve many of the problems that already have solutions in traditional C++ programs.
Personally I enjoy writing games that are able to access the wide, wide audience of the web. Would be beyond interesting to make it simple to interface between the desktop and the web.
That is probably more the domain of apps built with the language than the language itself, I suppose, but perhaps something that's useful to keep in mind during the design phase.
You could do worse than to read this: The Next Mainstream Programming Languages: A Game Developer's Perspective (PDF).
So, I don't want to really bust your bubble, but... maybe I should? As a professional game developer, I have to say that there really need to be three types of "languages" for game development.
First, there's your engine-level language. This is typically C++. It's all about performance. The artifacts of gameplay are not meant to be implemented here (sadly, they often are).
Next comes the gameplay language. This is lightweight, easy to understand, and designed for rapid iteration.
Finally, there is some sort of visual scripting language. This is the lightest of all and is geared toward non-programmers (level designers, etc.).
That being said:
Definitely check out UnrealScript. It's used throughout the industry (since the Unreal Engine is a cornerstone of FPS game development).
I would highly recommend supporting:
Concurrent programming (check out what CCP does with Stackless Python for Eve Online)
Network replication (check out UnrealScript, you can tag functions to run on either the server or the client, or to be safe to run on the client, etc.)
State (as mentioned) would be great. UnrealScript has this facility. This needs to be safely done (i.e., enter and exit at any point, complex transitions handled elegantly, etc.)
Good luck!
Falcon is a programming language that supports multiple paradigms like message passing, OO, functional, and yet the code looks nice and clean.
What do you think, does it have a chance to take off and be used as a general purpose programming glue language? Is it worth exploring? What are your impressions so far if you used it in real projects?
I've downloaded it. It's powerful, flexible, Unicode-aware, and in use in real-world situations, namely as the scripting language for AuroraUX.
Falcon is our scripting language of choice. "Simple, fast and powerful programming language, easy to learn and to feel comfortable with, and a scripting engine ready to empower mission-critical multithreaded applications." -- http://www.auroraux.org/index.php/AuroraUX:About
Speaking of Unicode, this is a real Falcon script:
// International class; name and street
class 国際( なまえ, Straße )
// set class name and street address
नाम = なまえ
شَارِع = Straße
// Say who am I!
function 言え!()
>#"I am $(self.नाम) from ",self.شَارِع
end
end
// all the people of the world!
民族 = [ 国際( "高田 Friederich", "台湾" ),
国際( "Smith Σωκράτης", "Cantù" ),
国際( "Stanisław Lec", "południow" ) ]
for garçon in 民族: garçon.言え!()
It currently has a small but active developer community and so it's currently at the state where the cool features are really solidifying. Given that the interpreter is currently almost completely unoptimised, it still runs at a very impressive speed.
I know of someone using for all the scripting in their game (replacing Lua) and as far as I know, they've found it a pleasure to use.
While it looks interesting, and has some cool ideas, I don't see much use in learning it unless it's used in industry and or academia.
The history of programming languages is littered with great languages that have fallen to the way side because no one adopted them.
Their features are however often incorporated into more popular languages.
That said Ruby was created in 1993 and rarely heard of it till it got used in Ruby on Rails. Now it's the next big new shiny thing.
So maybe in 2023 I'll be eating my words, but then again if Falcon is a good language and I need to use it then it should be easy enough to pick it up.
What do you think, does it have a chance to take off and be used as a general purpose programming glue language? no one knows!
Is it worth exploring? I guess any language is worth to take a look at
What are your impressions so far if you used it in real projects? I have not used it
Today a race exists to see who creates the most sofisticated language borrowing syntax among them.
Regarding easy to read programs, we can depart from assembly language (and esoteric languages!), following near english ones (C, Java, PHP and Delphi my favorite) and finally english like ones. For example, COBOL.
¿Do we really need a new language? hard to tell. Java was regarded a curiosity and quickly got strong influence in the industry. Dart on the other hand, promised a lot and still have not heard of nobody using it.
Where will Falcon will be positioned? Only time will tell. Personally, I find it's syntax too sofisticated (and also Java, PHP and C). I have been programming in Pascal for many years (and its variants) and prefer something like:
Writeln('I am ',age,'years old and my zipcode is ',zipcode);
Than C++:
cout << "I am " << age << " years old and my zipcode is " << zipcode;
I guess all programmers have a favorite (or in some cases only one) programming language. That leads to the saying "When the only tool you know is a hammer, all problems look like nails!" (perhaps the same can be said about database engines) How many users create "databases" using worksheets?
So, in conclusion I will explore it to enhace my tool box and have a hammer, screwdriver and even a sextant!