As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm building a new game and I need to build a web app to help manage content generation. The app would consist of a couple simple forms that would tie into a MySQL db.
I've been really interested in learning Lua for a long time due to it's large popularity in the video game industry and was wondering how well it works as a server side language. I could easily write the web app in PHP but I'd rather use this opportunity to learn Lua if it makes sense.
What do you all think?
Cheers,
Sure it can be done. Good idea if you just want to learn Lua. You should start here: http://www.keplerproject.org/
Of course, if your app would consist of a couple simple forms, you can use all what you want. But if it is more complex (will become more complex in future) it will be better to use some industry standard languages like Python or Ruby (or, at least PHP), there are a lot of good frameworks writen in them that very simplify your work (I don't know about any complete lua web frameworks) .
You should remember, that in future other people will have to maintain your code and there are very few web-developers who know Lua.
Probably, there will be problems with documentation and basic libraries too.
While LUA is a nice language for embedded development but i would extremely vote against LUA for web development.
The reason is that in Games you simply don't have an external API. All is done with your own objects only some calls into your game engine.
But the web world is so full of stuff you need, like SMTP, POP3, IMAP, SSL, Amazon APIs, Google APIs, RSS Apis, Imaging etc. and while the checklist for LUA may have a check mark behind all this words - it doesn't mean anything. Most of the stuff i have seen is just a "me too| implementation but not industrial strength. They are projects by hobbyists and are published on a "Its good enough for me" basis which is total unacceptable if you ever go mission critical.
There is a reason why it takes years and a huge community to get this up. Lua has an extremely small community of web developers.
So if this is a professional project where you put your money i can only say hands off. On the other side if you have enough money i still have some snake oil here for sale, please contact me.
I have been using lua for years as a web language. Initially using the Xavante project and more recently apache2.
Dont listen to any neigh sayers, its a great language for web developement and we use it to write business software, and not just for form processing, for graphical applications too.
Also it offers us seamless integration to any other lua or system functions we might need to call.
Good Luck!
Have a look at Nanoki which is built on a pretty minimal set of libraries (lfs, luasocket, lzlib, slncrypto)
and Sputnik which is built on Xavante or CGI
Lua is a good language but it is best suited to embedding within an existing project in order to quickly extend the capabilities of that project. In particular, the interesting aspect comes with how you bind it to the host application. This is definitely the case when programming for games where it is an embedded language rather than the language the whole app tends to be written in. So using a web app to learn about Lua with a view to making games is probably not a very good approach, especially since the syntax is very simple and would be picked up quite quickly anyway.
I think that specific variants of lua can be used successfully for web applications and I have done that in the past using the maintained weblibrary. It can depend on if the lower level software on the computer is itself written in lua because of its high speed and this may cause a clash of lua versions. Regarding a serverside possibility the server would need a compatible version of the script developing facility for the hardware and a suitable bytecode or VM instructions and custom VM runtime implementation for running the application.
I've been developing a pure Lua Web Server, you could always check it out and see if it suits your needs
Lua4Web https://github.com/schme16/Lua4Web
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I like to experiment with different languages to keep my interest alive when working on small side projects away from my day job.
I'm finding it increasingly difficult to steer away from Django and Ruby on Rails because of a couple of features they come packed with (or that are mostly default and easily integrated): authentication and automatic admin interface. Django comes with both, with Rails you just have to add ActiveAdmin as a gem and you're ready to go.
When I try to experiment with different frameworks and languages (Noir for Clojure, Express for Node), most of the times I find interesting languages I'd love to work with but whose "web framework" idea is just some convenience method for routing and parsing URLs and requests, leaving you alone with all the common and annoying parts of web development, like form validation, user authentication and profiling, having a working admin interface and so on, all things that Django and RoR provide to you for free.
What other languages and frameworks have such commodities? I'm aware of some PHP frameworks like Symfony, but I really have used PHP for too long in pas years and I'm pretty fed of it. Thanks.
Stick with RoR in my opinion. It's still a young yet powerful framework. It's well maintained and quickly plugged whenever a security risk becomes known.
It doesn't really matter what kind of MVC framework you use since it all comes down to the programmer. Ruby on Rails cuts out the painful part of programming (IMO) and allows you to do the enjoyable parts. Requiring knowledge of SQL is very minimal within Rails unless you're doing complicated scoping.
If I kept searching around for different languages to explore after I found one that suited all of my needs and then some, I would never get anything done. Moving from PHP/CakePHP to Rails is definitely an upgrade in my opinion, but at this point, you're better off committing to one language (Python/Django or Ruby/Rails).
I would stick with Django. Having worked in everything from classic ASP, ASP.NET, ASP.NET MVC, Java, PHP and Rails, I can state, unequivocally that Django is hands-down the easiest to work with, most profitable framework I've ever used.
Rails does have some pretty controllers, but it pales in comparison when you get down to functionality. Sure, Rails has lots of plugins, but Django has nearly everything you need under one roof. Django-admin alone is a friggin' gold mine. I work full-time as a Technical Architect, but also own my own business. Switching from Rails to Django in 2008 was the single best thing I ever did for my business.
If you want something flexible, modular, easy-to-extend and incredibly well documented - Django is your ticket. You also see far, far fewer of these lovely posts with Django.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am wondering what's the next logical step after developing applications with java play framework?
I really love to develop with play 1.2 but I am inconfident about its future, the main developers stopped their support on it (yet it is still opensource) and play 2.0 is a completely different product.
I tried to study play 2.0, but I just couldn't like the scala language (although it sounds like a great language to code)
So I decided to focus my web application projects to another framework. It shouldn't have to be java, but I prefer it to be a platform independent framework like ruby, or else. (I am also a .net developer with mcp certificate but i usually use osx enviroment for coding and I'm not a big fan of windows).
My Current problems with the play framework:
It works quite well but i dont see a future with it i am afraid the opensource community will stop developing 1.2.x after some time
Play 2.0 threads java as a second class citizen, and i am starting to losing my faith to its developers.
There are not much people looking for play framework jobs
The framework should be:
Platform independent
Database independent (can use hibernate
or else..)
Has a large user community
Has to be a proven framework with large enterprise applications
I've searched a little bit and I found grails, spring and RoR frameworks.
Ok then to make things clearer, heres a summary about my question:
Should i continiue from the "java" path?, i have concerns about time is changing and in few years, there will be more "scala" like functional languages used in web frameworks and they will be more useful in future frameworks
I am also wondering about Ruby langugage? Any insights about where will they be in the next 5 years?
Where do you see "Play framework with scala/java" in the next 5 years? Will they be worth the time invested on them?
Thanks for helping!
Spring.
If you know Java then a reasonable thing is to know Spring also.
People crap on Spring because they think:
Its not new and shiny
You need gallons of XML to do anything.
Its humongous monolithic beast.
Besides being mature none of the above is true. And unlike Play! Spring is in it for the long haul.
Spring also doesn't go off and build its "own" of everything but instead relies on best of breed libraries that you plug in. Thus with Spring you can play with what ever templating language, what ever build system, persistence, etc...
Now the only PITA with Spring is finding a good starting point. I recommend either Spring Roo or MWA
UPDATE:
I don't know why I got the -1 when the question was bad anyway (put a comment or something).
He asked for:
Platform independent
Database independent (can use hibernate or else..)
Has a large user community
Has to be a proven framework with large enterprise applications
IMHO There is not a framework that fits the above points better (particularly enterprise).
HE asked an opinionated question I gave him one.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been using Grails for the past few months and I really like it, specially GORM. However, I am getting interested into Scala's Lift. Therefore, I would like to know your opinion about which kind of web apps are better suited for which of those two frameworks or it is just a matter of taste, which framework to use?
Finally, which of those frameworks do you think will be more used in the future?
I have the feeling that Grails is far from reaching a critical mass and it still remains very obscure (in the past few months I had the opportunity to work with middle size companies and IT startups working mostly with the JVM stack and only one person knew and used Grails) and I am not even sure if it can become the "RoR" of the Java world (Indeed reports a drop of growth in the last few months even if other frameworks have a positive growing rate). And I love Groovy, it is really easy to learn but I have noticed how slow it can be for some tasks.
On the other hand, Scala seems to be more popular (Tiobe Index) and the fact that Twitter is using it now gave it even more presence in the blogosphere with lots of lovers and haters making buzz. It is famous for being fast and scalable. However, the language seems somewhat hard to understand and learn for lots of developers (so maybe it will never gain mainstream status). Lift is little known and I have read some reports that it is better suited for small apps (less than 20 domain classes).
By seeing the number of books published Groovy-Grails dominate right now, but many publishers have Scala books on the works, so I think this advantage will not last long.
Finally, we have the problem that both languages and frameworks still have poor IDE support (it is getting better by the day but far away from what Java shops expect to be productive).
I do not want to start a flame wars, but I would be very interested to hear other users' opinions.
The accepted answer here takes a really ignorant view on Groovy - it is a modern, dynamic language (dynamic vs. static is a huge debate in and of itself, and not particularly relevant here). This is by design, and therefore not a disadvantage, just a difference. It has a lot of modern language features that Java does not have such as closures, native regexp, polymorphic iteration, some optional static typing (matter of debate, but also look at groovy++), native syntax for lists and maps, etc.- you can see a comparison here http://groovy.codehaus.org/Differences+from+Java
To address the actual question of Grails vs. Lift, I'd say Grails hands-down. It has the SpringSource behind it, and just look at the plugins page http://www.grails.org/plugin/category/all - I can't even find what plugins or equivalent are available for Lift. Grails is also on top of the latest cloud-friendly technologies, with features like native RabbitMQ messaging support, and turnkey GORM support for MongoDB and Redis.
Grails is a nice idea(but only "stolen" from rails) but the fact that the groovy guys are not interested in getting proper Eclipse support is hindering it's success a lot. I've even seen Eclipse questions not being answered at all on the grails lists.
I agree with Tim that Netbeans 6.7 finally delivers the first half way usable Open Source IDE support for groovy/grails - and eventually, SpringIDE will also feature better groovy/grails support.
The reason many Java folks love Java is the static typing, which enables tools to help you a lot with many things. This is lost with a language as groovy.
Yes, I could write every really important piece of Code in Java and still use Grails - but then, why should I, just to save a bunch of lines of glue code, do that instead of learning to use a Java framework highly effectively?
To come to an end: I did not yet look at scala, but built some simple apps with grails - and I tend to go back to java, even reimplementing every app that needs further development in a plain Java framework - I think wicket and Seam.
I'll also look at Scala/Lift, I heard many good things about it!
BTW: I'd compare communities and look at mailing lists - how many peope are there, do they get good answers on their important questions?
Grails seems to have a non-answered rate from nearly 50%, which I feel is bad.
Grails support in netbeans 6.7 is really good, as well as the idea intellij support in Maia.
Eclipse is still pretty sucky.
I looked at lift, but was concerned about the resources available now; this will change in the future, but my projects can't wait.
I would like to specifically answer the question "for which kind of applications". The main difference between the philosophies of Grails and Lift seems to be that Grails enforces MVC whereas Lift seems to be more liberal i.e. it doesn't enforce MVC but provides enough avenues to use MVC if you want to.
Also Lift seems to be excellent for 'Single-Page Applications', especially if you need to implement a server-push functionality using technology like Comet (which obviously doesn't imply it's not good for other types of applications). On the other hand, Grails seems to be better for the 'Enterprisy' applications, especially if you are already familiar with Spring and Hibernate but want your app to be much more concise (using Convention over Configuration) than what a non-Grails app would be using these technologies.
References:
Simply Lift, chapter 13
Single-Page Application
Disclaimer:
I have just started exploring Lift and built some simple apps using Grails.
With all the performance improvements and advancements of Grails2.0, with great support provided by IntelliJ 11 for the framework, an ability to plugin pretty much any advanced web technology into your grails app., and yes - VMware weight behind it - I really don't see how Lift could be an advantage or a good choice. Just think of using two different languages in the same application, need for double expertise in the team, etc.
The original question has been posted like 2+ years ago and I think time showed on which side is the choice of the dev community ;)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm interested in building a site that has several interactive features for the users, yet want the site to be relatively light and avoid using Java or Flash. The site will start small but will hopefully be scalable. I realize developers tend to prefer a specific language and/or CMS and am wondering if you think a particular language would be best for creating a site with these features:
Short user profiles, photo upload, automatically generated thumbnails, a simple rating system, photo galleries, a blog section, ability to serve ads, user verification, polls, forms to enter contests, a taggable, searchable how-to library, a video library (using videos hosted on other sites)
I'd recommend you checkout Drupal CMS. Drupal covers almost all of your needs by means of drupal modules and/or drupal core itself.
Using drupal is easy, you don't have to be a programmer. Eventually you can hire a drupal programmer to take care of certain things that may not come with drupal or may not have any modules available. The other plus of a drupal programmer is that they are already familiar with the technology and can help you much more faster.
I would go for a python or ruby web application framework, say Django or ruby on rails, if this is going to be a single developer project it would probably make sense to leave it open on what framework to use - familiarize yourself with the frameworks and interview a wide variety of candidates.
Hire the best applicant and go for the framework of his/her choice - if he's any good, he can definitely tell why his choice is better than the other ones, not just claim that "it is" (or worse, it is the only one I'm familiar with)
wikipedia list of the frameworks
The best setup would be COBOL, with a UNIVAC on the back-end for storage and a vintage Enigma machine in between.
Or, alternatively, find the person you want to hire and let them decide. From the tone of your question, it would appear that you don't trust your technical abilities. What makes you think that you're going to get good advice from a bunch of random people on the internet?
Find a good consultant that has done work similar to what you're trying to do and let them decide on the tools. In the long run that will be the cheapest because paying someone to learn a new set of tools will be much more expensive than any other costs that might be associated wit ha particular set of software.
Any language will do the trick (although Prolog could be too tricky). Use what you know best unless you want a tradeoff for self-education in which case use the language you want to learn next.
I would recommend using Django framework which is based on Python language.
It's a tradeoff. "First with the worst" is a time-honored recipe for success. That would be PHP, huge first-place presence, cheap hosting, lots of existing frameworks, lots and lots of bad code. More sophisticated, in second place, would be Python. Yet more sophisticated, in third place, is Ruby. I'm not exactly sure where perl ranks in web development.
Note that you will tend to attract a slightly different kind of partner/developer/employee with each choice.
If it were me, I would go with Ruby plus a framework, perhaps RoR, unless one of the PHP CMS packages was really close to what I needed.
So much for opinions, here is a language and platform agnostic thing to consider: with the recent availability of cheap VPS hosting, you really can have any kind of site you want, yet you don't need to run your own machine room. It makes Java and the other JVM languages more attractive, I think.
If you want cost effective solutions then I will suggest you to go with LAMP. You will get almost all your required features in free open source scripts. Again the development of LAMP is comparatively cheap then ASP.Net.
By LAMP I mean Linux, Apache, MySQL, PHP.
The hosting expenses of LAMP are also comparatively cheap.
There is no absolute answer; You will have as many answers than users.
Do not re-invent the wheel!
First of all you will need to define your wishes - almost done.
Then choose a product regarding to the price.
Finally, find a specific employee.
For your needs, you can look at:
joomla
sharepoint
eroom
openText
blog platform
framasoft, chapter CMS
Some thoughts:
I highly recommend against Drupal. My experience is that it is entirely too bloated to be considered less than obese (let alone light).
I've heard NOTHING good about wordpress.
Joomla has a good reputation, but it also has the reputation of having a higher learning curve (I've never spent real time with it). If you're hiring someone, however, this should be irrelevant.
Personally, my favorite systems in PHP are from EllisLab Inc. -- Expression Engine and Codeigniter. Both of these are very well written and generally lay a groundwork for reliable and maintainable code.
Ruby generally has the reputation of being simple enough to build in.
I would use caution with Python, because it is in the midst of a transition between incompatible versions and that could be hell.
I'd go for ASP.NET.. it's trivial to build the things you mention with WebForms, although I would go for MVC in a larger project.. just my 2 cents..
as far as hosting expences goes Windows and Linux is nowadays pretty much the same...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
As I'm riding the wave of resurgence of Smalltalk (especially because many Ruby-on-Rails people are rediscovering Smalltalk and seeing Seaside as their next upgraded web framework), I get questions like "yeah, but how do I use my favorite editor to edit Smalltalk code?" or "Does Smalltalk still insist on living in a world of its own?".
Now, having first experienced Smalltalk back in 1981, I don't understand these questions very well. It seems rather natural that I'd want the editor and debugger to be savvy of my current code state, and integrate with the change control system that is Smalltalk-aware. Using an external editor or debugger or change control manager would seem very awkward.
So what is it that scares you the most about not being able to edit the five-line methods in Smalltalk with your favorite editor, or use your favorite non-Smalltalk-aware change control system?
Everything's different. Want to go to the end of the line? It's not Ctrl-E. Want to jump a few words over, by word? It's not Meta-F....
Text editing is a fundamental programming activity. Messing with those inputs is messing with something deep in my mind.
Edit: and here is someone asking for emacs key bindings on comp.lang.smalltalk in 1987.
The only Smalltalk I've spent any time with is Squeak, so my views may not apply to other Smalltalk environments.
What concerns me about the image-based approach is that, while you have wonderful things in the Smalltalk environment, it is a walled garden that makes it difficult to interoperate with anything outside that environment. For example, what if I want to use external tools like Yacc and Lex? What if I want to use some C or Python programs to generate Smalltalk code? What if I want to mix Smalltalk in with a bunch of code written in other languages, editing code in all those languages in one editor and keeping it all stored in the same source-code tree?
I'm sure it's possible to deal with all these issues by having your Smalltalk environment invoke system functions to control external tools. But how easy is it to let external tools control your Smalltalk environment? In other words, what if I want Smalltalk to be just another component, rather than the master of everything?
Nothing scares me in particular, but I found working out the API's in VW a bit of a chore, even when I had used other smalltalks. The effect of the browsers is that you tend to see the API's a little bit at a time and quite often it's not immediately obvious where you should look for particular functionality.
Smalltalk also suffers a bit from the paradigm shift to understand how it works. When I was doing my bachelor's degree at university (some time after I had first encountered Smalltalk) I got to enjoy a bit of Schadenfraude watching everyone else in the class getting over the initial paradigm hump as they learned the system (Squeak) for the first time.
I think the combination of the paradigm shift and functionality being somewhat buried in the class libraries makes for a bit of a steep learning curve. ST had a reputation for a fairly steep learning curve to really come up to speed - most of this is due to the large class libraries and the fact that most of the language functionality is buried somewhere in the libraries.
Also (and sadly), Java came along in the mid 1990s and grabbed all of the mindshare. The major Smalltalks have either died completely or been sold off to niche players. It's quite Ironic (in a happy way) that Ruby has served to re-awaken interest in Smalltalk but the lingering perception of 'also-ran' obsolescence doesn't help.
See This post of mine for some pontification about the merits (as I see them) of getting heavily involved in Smalltalk in this day and age.
I would be quite happy to go back into Smalltalk if the opportunity were to arise.
The one big show-stopper for me is that code I write one Smalltalk VM is STILL, after all these years, not compatible with other Smalltalk VMs.
I understand why that is: the core of Smalltalk is an extremely small set of axioms and keywords. This means that after 30 minutes of learning Smalltalk, you're already learning the API library rather than the language itself. I like that approach to language design.
What it all boils down to however, in the Smalltalk world, is that unless a consensus is reached between all VM vendors to have a common base Standard API, my Smalltalk code written for one VM is almost certain not to run on other VMs when I decide to switch.
This also has the corollary of obsoleting part of my knowledge of the space when I switch VMs.
Note that I have barely tried Smalltalk in my life. I'm far from being an expert. This understanding comes from speaking with James Robertson about a month ago.
Another point I'd like to make is that Seaside does in fact run on most popular Smalltalk VMs. I wonder how much of (what should have been) a Standard API they had to build for themselves to achieve that feat.
With all that said, I always have an ear out to hear more about the state of Smalltalk. I do want to try out Smalltalk's very powerful development environment (and its other goodies).
I know it's late but the biggest annoyance for me is that there is not really good editor in none of the smalltalks. It's a thing I can not understand. Working with text is so essential and that less "supported"....
It's always this just staring at one method and then you need to have some method finder or another browser around just to check another method. This is what I really dislike....
While the restricted Smalltalk environment made things like relying on a database driven source control system possible at times where other languages still struggled with having a proper editor, it makes integration very hard in todays times.
With tools like Eclipse or Team Foundation Server you get so used to having all tools integrate with each other. E.g. if a requirement is created, it is automatically linked to the change sets that the programmer commits to implement that requirement. This "boundary breaking" between formerly different tools is nearly impossible in the Smalltalk world, but with bigger projects, bigger teams, higher levels of abstraction and so on you need tools which are more than a fancy editor and help you throughout a full software development life cycle.
No useful support for navigating with the keyboard, or supporting platform UI behavior.
While it's true you don't really need an incredible text editor for (well-written) Smalltalk, being able to move around the environment while keeping your hands on the keyboard is quite useful (and in my case, essential to reducing RSI). I just was trying VisualWorks' inspector and the arrow keys didn't even work properly to move up and down a list. When I hit the space bar, I got a walkback. Sigh.
For the Windows world, there is nothing like Dolphin Smalltalk. The IDE is fantastic. Another quality product if you want to try is Visualworks, it works well, has a very fast VM and the documentation is pretty good.
I've used both in the past, there is nothing to fear.