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.
trying to get a side project hobby going to keep me motivated from my 9-5 job on C# and was looking at Boo. some ?'s
what has your experience being with Boo?
what kind of apps/projects have you done with Boo or
what is Boo capable of?
Guess being the web world, would like to get my hands dirty with desktop applications etc.
My personal experiences with Boo were from about 18 months back, and I've not followed it actively since then, so keep that in mind wrt to what I say. It is a cool language. But it is also experimental. What this means in practical terms:
You can do cool things w/ the language. The macros they allow, plus mixing in good features from ruby and python and other languages.
There is a WinForms designer you can use via SharpDevelop (which has Boo integrated as a standard development language).
There inconsistencies and bugs at occasionally critical areas because it is not done yet.
I'm not sure if Generics can be created yet w/ Boo, but they certainly can be consumed.
Performance is good, but the compiler doesn't have an optimizer.
Type inference is cool. Duck typing is cool. All that lets you approach the illusion of dynamic typing.
Personally, I worked on a tool to make creative writing easier. Think IDE for writers.
While it only uses Boo as the implementation language (rather than being fundamentally about Boo), have you read Ayende's "Building Domain Specific Languages in Boo"? It's not fully published yet, but you can get an early access edition.
I haven't had time to look carefully at Boo yet, but the main advantages over C# 3 (which gained some of Boo's features) appear to be terseness (lots of type inference) and metaprogramming.
Boo is very powerful tool for DSL creation (external and internal)
Internal DSLs can be created using Macros, Meta-methods and extendable compiler pipeline.
The extension of Boo language - Boo.OMeta.Parser can be used to create external DSLs.
Currently the parser is under development but it can already be used for creation of complex external DSLs. OMeta is powerful tool which enables programmers to easily implement lexical analyzers and parsers. Extendable compiler pipeline architecture of Boo allows to replace standard Boo.Parser with Boo.OMeta.Parser. It can be used to extend Boo syntax with almost any kind of syntax.
The example can be find here.
I am working a side-project with Boo to implement a declarative data-binding macro. The language is pretty cool! It is giving me some experience in compiler construction that I haven't had.
Just for fun I am working with Boo on Mono on Ubuntu 8.10.
Some usages that really fit the dynamic mindset of Boo:
Brail view engine
BDD with Specter
Embedding Boo in your nant script, or even building a build system from scratch
Embedding a 'shell' to interact with a live web application.
You should have a look at some of Boo's interesting language features.
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.
What language, between Go and Rust, would you use to create a library for games (no bindings)?
Go is a simpler language that leans more heavily on garbage collection. Rust is a more complex language that can be safely used without the GC at all which is perfect for low-level systems programming.
I'm biased since I spent two summers working on Rust, but if you're willing to invest the necessary time to keep up with a rapidly changing language, Rust would be really good for games. It has a really nice set of built in concurrency primitives, so it would be easy to separate the different components such as the rendering engine, the AI, etc. and take advantage of multicore computers. It's also possible to avoid the need for garbage collection, so you don't have to worry about unpredictable GC pauses. It's designed to integrate nicely with existing C code, and many of the data types map directly onto C types. Rust's approach to polymorphism leads to some really nice assembly once LLVM is done with it.
Many games nowadays are running in the web browser, which suggests that web browsers and games have similar requirements. Mozilla is designing Rust alongside its new parallel browser engine, which means the language will continue to evolve in ways that would work well for game programming too.
Rust: This is alpha-level software with many known bugs, incomplete features and planned future changes. Use at your own risk, expect some instability, disruption and source-level incompatibility for a while yet.
No good for commercial game.
You can't make library with Go for games at all. There is no support to create library in Go. With Go you can create mobule(library) that you will use only with Go.
You can use C++ library in Go. But you can't use Go lib in C++.
You may ask what language is better for games Rust or Go.
UPDATE 2015 year
Go 1.4 has office/beta support for Android and Go 1.5 (2015 Summer) will have iOS support.
Right now it is tricky to build for android. You have to install docker image
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 advocating using Scala at my company. One of my co-workers forwarded me this link tonight
http://blog.joda.org/2011/11/real-life-scala-feedback-from-yammer.html
I was hoping to get some constructive feedback from the SO community about this. I don't want this to turn into a flaming thread, but if there are legitimate concerns floating around out there I think it would be beneficial to discuss possible reasons and best practices that can avoid others falling into such traps.
I will say that I have been loving Scala and have not run into any of the problems that are mentioned. My application is also not very hashmap intensive, which appears to be where a fair number of their problems came from.
[Edit - apparently I need a question!]
The question is, do you think that the problems described are systemic to Scala, or more unique to their environment? If they are systemic, are there some good guidelines for a company that is just getting started with Scala to follow so that they don't end up in the same boat in 2 years?
Issues Described
Language Complexity
Systemic issue. Scala is unlikely to get less complex, whether or not that is a problem depends on the developers that are working with it. For me, it is complex enough to keep me interested and engaged, whereas pure Java can be mind-numbingly boring. My suspicion is that if Scala is way too complex for a particular developer, it is unlikely they're going to be top-notch dev when it comes to Java as well.
Community
So this one guy says the only way to do this is with a bijective map
on a semi-algebra, whatever the hell that is, and this other guy says
to use a library which doesn't have docs and didn't exist until last
week and that he wrote. The first guy and the second guy seem to hate
each other. What's the Scala way of sending an HTTP request to a
server?
That quote is pretty funny, but this is obviously a non-systemic issue with Scala. His main complaint about a lack of consensus regarding best-practices is relevant to all up-and-coming languages. I think Java developers have been spoiled in a way -- having gotten used to being part of such an enormous community where pretty much everything has been done before and possibly already standardized.
Build Toolchain
Another non-systemic issue.
Performance
This one does worry me a little bit and I can see getting frustrated very fast having to uncover previously unknown performance gotchas. I suspect for years to come there will be some pretty big performance penalties depending on how you use certain aspects of the language -- so people will have to exercise caution and make their own analysis regarding each project's performance requirements.
I concur with his sentiments here:
Despite the fact that we're moving away from Scala, I still think it's
one of the most interesting, innovative, and exciting languages I've
used...
And finally I would urge people to read Stephen Colebourne's blog with some degree of skepticism, because his personal disdain for the Scala language seems a bit oversize relative to the arguments.
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 considering writing an app that has the following requirements. I'm proficient with Ruby, but I'm willing to learn a new language like Scala, Clojure or Python.
Concurrency / Best performance
This is my main goal. It needs to be amazingly fast and support concurrency in a decent way.
Use Redis as a back-end
This won't be a big problem, redis has a wide range of drivers available, but it may influence the final decision on a language/platform.
Websockets support
Good support for websockets is a must. Using an add-on library (like Cramp for Ruby::EM) is okay.
Options
I've gathered the following options:
Ruby EventMachine
Python Twisted
Node.js
Clojure
Scala
Java
Writing raw C or assembler are not viable options at this time.
Concurrency
Ruby 1.9 still uses the GIL, where as all JVM based solutions can use native threads. I'm not sure about Node.js in this case.
How does the selected language affect performance?
The question
What do you recommend and why? Do you have hands-on experience? Please enlighten me (and the rest of StackOverflow)
Clojure is about twice as fast as node.js, which is about three times faster than Python which is held to be faster than ruby.
I'd vote for Clojure if high performance concurrency is your main criteria. Clojure was basically designed for concurrent development from the beginning, and there have been some impressive Clojure demos running on 800+ core Azul boxes.
It is very much worth looking at this video presentation to understand Clojure's approach to concurrency:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
The main trick in Clojure's concurrency performance is a clever implementation of Software Transactional Memory (STM) that lets you conduct many concurrent transactions without complex and expensive locking schemes. It also uses persistent data structures to give immutability and efficient management of multiple versions of data. It's very cool.
As for general purpose performance, Clojure is pretty fast already and getting even faster with the new 1.3 alpha branch. A stated aim of Rich Hickey (Clojure's creator) is to allow you to do anything in Clojure with the same speed that you can do it pure Java.
Other things in Clojure that I really like but may or may not be relevant to you:
Hugely powerful LISP-style macro system - "code is data" and you can manipulate it as such
It's a fully fledged functional language
It's dynamically typed by default (for flexibility and quick prototyping), but you can add static type hints if you need to (for better performance)
Excellent JVM / Java integration, so you can make use of all the good Java libraries and tools out there (e.g. Netty for event-driven server communications)
On Clojure you could use Grizzly for async http processing and comet/websockets based apps.
Redis is a great choice to cache and create a powerful distributed session with pub/sub protocol built-in
Another big thing is use RabbitMQ or ZeroMQ to simulate a agent based distributed system and provide group, data or integration services for example.
Is relative ... a like clojure a lot and agree in parts with you , where clojure is one of the fastest language on jvm .
But the knowledge on language is essential and could confirm our feeling.
Some interesting links on benchmarks , performance and comparisons :
http://bit.ly/dtqHAG
"Premature optimization is the root of all evil", by Donald Knuth
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.
Someone told me to use MFC,but it seems that MFC will be dead,although its not already...
so if i want to learn windows programming now, which one should i choose? thx.
I encourage you to learn C#, personally is one of the best programming languages for windows nowadays (personal opinion)
If you want to go to the raw Win32API (Which I think you will learn the most and a must-have for your bookshelf)... Charles Petzold's Bible is a must-have... MFC, ATL, C# Winforms are all basically wrappers for the true API architecture using nice properties/events....
If you really want to learn windows programming, start with Petzold's Programming Windows book. You'll get a good understanding of how Windows actually works, which is invaluable when dealing with the more abstracted frameworks.
Then skip over to Windows Forms or WPF. MFC isn't worth the headache.
If you are going to program at the windows api level, you would be better off using something like Qt.
learn plain win32 API not waste your time on MFC ... that is my opinion
I'm with Andres on this one, learn C#.
Additionally you might consider working with java some. There is a huge knowledge base there and in my experience it and C# cross over a lot in syntax and form.
If you are looking for problems consider Project Euler or Programming Praxis
If your goal is to learn the Windows API, MFC isn't a bad place to start. It's a really thin wrapper around the API, nearly transparent in most cases. Perhaps the biggest difference is in the message handling mechanism. In MFC you use macros to generate a table of message handling functions, and many messages get rerouted automatically from parent to child or vice versa. In a raw API program you'll typically see a message loop with a huge switch statement, and it all gets handled in one place.
Depends on the type of application you want to create? The latest forms-based programming is WPF... that is the latest and greatest, but Windows Forms programming is also an option too (there's a lot leveraged in this still).
HTH.
Depends, like everything in the IT world depends of what you need.
But C# or Java is a good start!.
WPF or WinForms with C#.
With WPF you can create very flexible GUIs, WinForms is more traditional.
Try Expression Blend for creating GUI (WPF) and Visual Studio for coding :)
Well it depends on what you want to do. Are you new to programming in general? If so then I would suggest picking up a good programming book or going to a college and enrolling in a CS degree program.
If you already know how to program and just want to write windows programs you have several options. Which one you pick depends on what you want to do and who your target audience is.
Win32 API - The lowest level you can get. It's OLD OLD OLD school C code, but you can write small fast good looking programs. You have to do pretty much everything yourself. The Win32 API is pretty complicated and you have to know the ins and outs to write the best code possible.
MFC (Microsoft Foundation Classes) - Takes the Win32 API and encapsulates it in C++ classes. It's again OLD OLD school but has recently been upgraded from MS with the new 2008 feature pack so it's far from dead.
.NET (C#, VB) - The brand spanking new stuff from MS. It's incredibly easy to write code and create programs. However it does hide all the lower level stuff from you so you just write C# or whatever and it always works.
And of course you can always write in Delphi, Qt, WxWidgets but these are simply wrappers for the win32 API.
As far as my personal choice goes it depends on what I'm doing. At my job I write C# because the hardware/software is under my control. I know what version of the framework is going to be installed, how much RAM, hard disk space, etc. For my own projects I create I almost always use MFC. It hides the nastiness of the Win32 API and gives me C++ power. Would I prefer to make everything .net, absolutely but I've found not a lot of people have the .net framework installed so I was severely limiting my user base.
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.
When it comes to scripting the Mac, are there alternatives to Applescript? Its API seems awesome, but the language itself, from what I've read so far, seems aimed more at non-programmers.
Insights into this would be greatly helpful.
(At the moment, I'm thinking of writing a tiling window manager for the Mac.
Yes, I know some exist, but this will be open source.
Yes, I know of Xmonad, but it only does X11 windows.)
Thanks!
When it comes to scripting the Mac, are there alternatives to Applescript?
Depends what you want to do. If you want to send Apple events to other applications, yes; for running scripts from OSA-aware applications (Mail rules, folder actions, etc.), not really.
The best technical alternative is appscript (my baby), which is available for Python, Ruby and Objective-C on 10.4+. (There's also a MacRuby version, but I've yet to do a public release of that.) Feature-wise appscript's slightly better than AppleScript and its application compatibility is very nearly as good. Third-party project, so you'll need to install it yourself (but that's easy enough as long as you've got Xcode) and MIT licensed so you can redistribute it as needed (e.g. included in your application bundle). Fairly decent tool and documentation support, including an online book by Matt Neuburg, with mailing list support for the Python and Ruby versions and direct email support for the others.
The 'official' alternative is Apple's Scripting Bridge. The API looks very Cocoa-like, but that's really just a lot of smoke and mirrors which ultimately makes it less capable than AppleScript and significantly more prone to application compatibility problems (and tricky to troubleshoot when it does go wrong). Tool, documentation and community support is not so great either (appscript's is better; AppleScript's is better still). SB's main advantage is that it's included in 10.5+ so requires no additional installation to use. I wouldn't recommend it for heavy-duty automation work due to its technical shortcomings, but for modest automation tasks involving obliging apps it may suffice.
Other bridges do exist (e.g. Perl's Mac::Glue, RubyOSA), but they are not as capable, popular and/or actively supported.
All that said, if you want to do any serious application scripting, you will still have to learn AppleScript as that's where you'll find the vast bulk of literature, sample scripts and community expertise. All of which you will need, since the great majority of scriptable applications are notoriously under-documented.