Has anybody had any experience accessing the Autocad or Inventor API with Clojure?
If you can access autocad through Java, then you can get to it from Clojure. I found this SO question on that matter. (http://stackoverflow.com/questions/856973/interfacing-autocad-with-java) Basically they've built a JNI bridge to the autocad API. Once you do that then you can access that through Clojure. It sounds like a non-trivial undertaking though to say the least.
I'm pretty old, and the last time I checked (cough 20+ years ago cough), Autocad was extensible via Autolisp. If that's still true, then would you really want to bolt on Clojure? Just curious.
As far as I know, AutoDesk exposes API for their products in .net environment. There is a paralel clojure implementation in Microsoft clr (.net environmet).
https://github.com/richhickey/clojure-clr
I think this would be a better way to aproach Autocad Scripting.
Related
is there anything similar to unity but with the difference that instead of javascript I can use C++?
It is funny, I was looking to learn a little bit of unity as I seen it as requirement for some postings... and I found this question.
I think Ogre3D is great... it may be what you are looking for.
here is the link ogre3d.org
Ogre3D is what I used. http://www.ogre3d.org/
It is somewhat of a misconception that Unity uses Javascript. The so-called Javascript used in Unity is actually a dialect of Javascript that is CLI-compatible and is not exactly the same as the official Javascript. Also, you are not limited to using Javascript in Unity. You can also use C#, which is similar to C++ and Java in some ways or the less commonly used Boo script.
Personally, I would recommend using C# in Unity because it is very powerful and allows calling of native C/C++ functions via P/Invoke. Here is a link to the use of plugins:
http://unity3d.com/support/documentation/Manual/Plugins.html
Link to list of Game Engines. Please take your time to read and consider them:
http://en.wikipedia.org/wiki/List_of_game_engines
If you want accessibility offered by Unity, C++ is certainly wrong choice. Much better would be interpreted/script language, such as Python. They are more flexible in terms of working in web browser/many os-es.
If you're interested in targetting mobile platforms then Marmalade might be a good fit.
Panda3D It's not a think compared to Unity, but it can work as a web plugin, cross-platform. It has a lack of IDE, but it is opensource.
As far as I know, there is no need to use JavaScript or Boo with Unity, and there is nothing wrong with C# acting like script language ( which is really hard with C++ ).
as a unity developer, I liked to add c++ to by knowledge base as all AAA games are made by C++ and I was looking for something like unity but for CPP. the only good cpp engine is unreal that doesn't really support c++. the language is a dialect of c++ and there are big differences. like very
rare usages of pointer and references
more syntaxes like c# attributes(cpp has not attribute)
...
so you don't learn memory management. the nearest thing that I could find was COCOS2dx as the whole framework is written in pure standard c++ and many libraries like UI and Physics are already added. you can write your own engine and editor with it.
Unreal Engine uses C++
default standard is C++14
https://www.unrealengine.com
I've decided to look into Clojure (inspired by this book). After a bit of research I've learned that I may be able to take advantage of my .Net experience by using ClojureCLR rather than needing to learn the various Java libraries. However, I have found very little documentation on the CLR version of Clojure (even the official website seems to push you to the JVM implementation's documentation).
Does anyone know where some decent tutorials, books, articles or documentation can be found? If there really are none, is it safe to assume that I can learn via the JVM implementation for most of what I need to know (i.e. there is little difference between the two implementations, so the knowledge will be fairly transferable)?
If need-be I am willing to learn the JVM version and the Java libraries (would be good to expand... which is why I'm looking into a functional/lisp language in the first place).
For now you will likely find a smoother learning experience for Clojure using the JVM. There are a some really exciting new ideas in Clojure and regardless of the platform you choose these will be a lot of fun to learn, though you may find it easier to concentrate on what you are trying to learn if you are on the platform with better tooling and a bigger community.
The part of the language that makes Clojure, Clojureish will of course be exactly the same, and once you're comfortable with them then the CLR side of thing will likely be more accessible. I get the impression that the general consensus is that once Clojure is implemented in Clojure the CLR version will track much more closely to the JVM development.
Clojure has attracted a huge following* of enthusiasts with no Java or .NET experience at all (those coming from Lisp) so I don't think that the differences between .NET vs JVM are a common stumbling block.
*Arthur's opinion :)
There is a blog devoted to the Clr version of Clojure that may interest you here. I believe the contributors are both the original Clojure creator (Rich Hickey) and the CLR port creator (David Miller).
I want to develop a new powerful GUI for an existing C++ application. I planned to do it as a standalone project in C++/QT, and it would communicate client-server with the existing application.
Recently I've been told that there is another possibility, to create such GUI using Eclipse. I mean that Eclipse can serve not only as an IDE, but also as some kind of framework for new applications.
Is it so?
Is it a good idea to use Eclipse in this way? What to consider?
Can such development be C++ based, or only Java based?
Yes, absolutely, the Eclipse "Rich Client Platform" is an application framework comparable to Qt, in some ways, and superior in other ways. RCP's frameworks are generally more sophisticated and more powerful than anything in Qt. Yes, I realize I'm inviting flames, because people do have religious wars over this. I don't care, I'm entitled to my opinion.
You could include C++ code in your application using the JNI API, but in general, the bulk of the development would be in Java. Ultimately, the deciding factor may just be the resources and skills you have available -- does your team know Java, or not.
As others have said, Eclipse is a platform, not just an IDE, but development using it is definitely in Java. Here's some reference material in case you decide to pursue this approach:
http://wiki.eclipse.org/index.php/Rich_Client_Platform
http://www.vogella.de/articles/EclipseRCP/article.html
Eclipse is built with its own GUI framework - SWT. It is Java-based but apparently there is a way to use it from native C++.
Eclipse is indeed a platform, with the cross-platform UI toolkit SWT and the OSGi plug-in system at its heart. Look at Android: a lot of the operating system is coded in C++, with hooks for normal UI development with Java. This is kind of what you need to do. Be aware that JNI is a pain and is certainly not easy to use, but I'd advise Java for everything except for code that needs to be accelerated, which you would do in C++. Java is fast enough for most tasks.
You can certainly do that. You might also consider Netbeans or Qt's own IDE as well.
I'm planning some Symbian related development on S60 3.1 platform. It seems like generally available language options are Python and C++. However Nokia's official forum seems very much tilted towards C++.
I want to know what are the advantages and disadvantages of using Python for S60 over Symbian C++? And is it even possible to do Python programming for S60 3.1 platform?
PyS60 is good when you need to prototype something simple fast. If you try to develop a full application with it though, you'll most likely find yourself sooner or later wanting to use features that are available in Symbian C++ but not in PyS60 without writing bindings (in C++) for it. Also you'll need to deal with the right version of PyS60 runtime being available, and some of them aren't backwards compatible.
If you go for the Symbian C++ route, you can embed a python interpreter in it too.
C++ is very, very fast, and the Qt library is for C++. If you're programming on a mobile phone, Python will be very slow and you'll have to spend ages writing bindings for it.
I answer this as a user.
PyS60 is slow and not so much app and sample to start with.
C++ is good, native, fast, but if you mind deevelop app for most device (current N-series), you will not want to go with Qt, I have a N78 and tested Qt in N82 too, it's slow (more than Python, sadly but true)
PyS60 has a very limited API. Applications written using it are slow, hard to deploy (since you have to install the runtime first) and cannot be posted on the Ovi store. If you're looking for an easy way to write simple Symbian apps take a look at Nokia WRT.
If you don't mind C++ try the recently released Qt SDK 1.0. It's really powerful, future proof and will soon be supported by the Ovi store.
What is the purpose of your programming? Are you planning distribute your app through Ovi Store? If so, you should use a tool that could be tested and signed by Symbian Signed.
What does it mean? As far as I know, they don't provide such functionality for Python. So you have to choose native Symbian C++ or Qt.
By the way, Qt signing procedure is not quite clear for now. It seems Ovi Store and Symbian Signed are only allow Qt apps for a certain devices (Nokia X6, Nokia N97 mini, maybe some other). I suppose it is a subject for a change, and quite fast change, but you should consider this too.
When 3rd edition Feature Pack 1 ran the latest phones on the market, the main runtime people were using to program them was J2ME (http://www.forum.nokia.com/Develop/Java/). I know the title pits C++ against Python, but have you considered Java? It was much easier than native Symbian C++. The performance is good.
-jk
Being a C#/Java programmer, I really need to know a fact: Has Windows Programming with Win32SDK/MFC/wxWidget become antiquated?
What is the status of popularity of these technologies in software industry now?
Being a C#/Java programmer, do I need to learn Win32SDK/MFC/wxWidget now?
I think that learning the Win32 SDK is useful because it helps you understand how Windows works internally. I found learning about hooks and subclassing very fascinating. So if it interests you then you should go for it. However, you probably don't need to know Win32. It's not yet antiquated today but it may be in the future.
I never had much interest in MFC because it requires the paid version of Visual Studio.
Yes, learn Win32, even if don't ever intend to write or maintain C/C++ apps.
No, don't bother learning MFC/wxWidget now. MFC does come with its source code, so you can study how some classes implement wrappers for Win32, but that is more interesting to C++ programmers. MFC is has decreased in popularity, though Visual Studio continues to support this older tech. Learn MFC/wxWidget only for an as-needed basis, if you need to maintain some older code.
With C#/Java, you can solve a lot of problems, but there are times when you will need to use Win32 directly to achieve some task. for a variety of reasons. Maybe some functionality is simply missing from .NET/Java, or has a bug that can be avoided by going directly to Win32. Maybe your particular problem to solve has unusual or strict requirements, and you would consider writing a portion of your app in native code using some Win32 calls as necessary. Lots of examples/situations really.
Another reason to learn Win32 is that both .NET/Java are higher level abstractions (which is in itself a good thing), but it really does help to understand the internals for these reasons:
You get an appreciation of how much work .NET/Java do for you. Of course, you can do the same things in C/C++, but it takes a lot more work. Consider these two compelling .NET technologies, WPF and WCF, which do a lot work for you.
You will better understand resource management. Specifically, both .NET/Java are garbage collected environments, but you must deterministically release OS resources (explicitly calling Dispose), for such things as network connections, window handles, kernel objects, and plenty more. You should never rely on the garbage collector to release these objects for you, since the GC is non-deterministic.
Debugging, knowing the internals seriously helps here.
Knowing Win32 can sometimes help explain the API design in .NET at least. Some parts of the .NET API are modeled on Win32 API, but some parts of the .NET API are extreme improvements over some truly heinous Win32 API designs (consider the API for using GDI for example).
Finally, knowing Win32 can help solve performance problems in your apps.
Win32 won't become antiquated, until the Microsoft's popular operating systems are based on something else. At one point, Microsoft was going to replace Win32/64 with .NET in Vista, but this didn't pan out. Even for whatever replaces Win32/64 is the future, you still need to understand the OS SDK. At the risk of sounding like a salesman, I will say that learning Win32 will in fact help you write more robust applications and will greatly aid your debugging skills, two important items to help you stay employed. I would never hire a windows programmer who doesn't have at least some experience with Win32.
I would suggest "Windows via C/C++" by Richter/Nasarre, as one example of a good book on Win32 (yes, it's obviously geared towards C/C++, but these authors do an excellent job explaining Win32).
Hope this helps.
I think Win32/64 SDK will never be antiquated, as drivers or other low level programs won't be written in .NET or Java because of the performance requirements. If you are going to develop in .NET, then MFC or wxWidget is useless for you.
I develop in .NET regularly, and sincerely, every program I've ever created in .NET called some Win32 API functions. So learning Win32/64 SDK isn't pointless, but is time-consuming.
I am an architect and I recommend that all new projects use newer technologies, like .NET or Java. The difference in productivity is tremendous, at least according to my own experience with C++ and .NET.
There are two exceptions:
- I work for a software company and we are bound by the requirements of our customer, usually including the programming environment. So, if a customer only has people knowing, say, MFC, we will make an MFC project. But this is becoming rarer and rarer. If we have the choice, we will go with .NET or Java.
- You have a team with expert people in these older technologies and they are quite productive with them.
There's plenty of work for people like you, so I'd advise not learning these for job purposes. We have some MFC apps, but that's partly because it's what we had and partly because we had more faith in C++ performance, and performance is very important for them.
I wouldn't call C++ or MFC antiquated, but there's relatively less new work in it. (I would very much like to never support another Win32 program, though.) The new C++ standard should be out in 200B, and people will continue to work on it, and Microsoft has been adding new classes to MFC, so obviously there's continued interest and continued work.
For professional development, I'd suggest you learn something different, but that would be something like Lisp or Haskell, rather than C++, and as far as I can tell there's no particular virtue in knowing MFC.
Realistically Microsoft forces business to use their latest and greatest technologies. There will always be work for someone who knows both technologies because someone has to port legacy code.
Many small devices (phones) or games require lighter solutions. If you intend to work in those areas you will definitely need those technologies.
You need to decide where you want to go. Once you have a map then you can lay in the right supplies for the journey.
I found Java horrendous to work with compared to Win32. Someone needs to cut about ninety percent of the inbuilt libraries.
I wouldn't call Win32 and such antiquated. As other people have said, it really depends on the app. As a game developer, I use Win32 less and DirectX a hell of a lot more. I could double or triple my Windows code, and it would still be an extremely small portion of the project.
However, if you're writing a primarily interface application with a relatively small and lightweight backend, .NET might well be a good choice for you.
As for Haskell, I just found that to be a truly terrible language in pretty much every respect. It seemed to me that it served some abstract mathematical definition of "functional", rather than a real definition of "programmable-in".
Win32 SDK is nowadays used in niche markets, where more modern technologies can't be used for some reasons (legacy Win32 systems, games, system drivers, Windows Embedded systems). If you aren't planning on pursuing a career on these markets, I wouldn't bother learning Win32 now. It is not that is useless and has no new things to teach you, but let's face it, there are so many new technologies coming out even at the time we speak. I have a dozen of technologies/languages in my waiting list to start learning and experimenting with. You can certainly find more interesting and more career favorable technologies to learn.
Performance critical apps (games) typically use C++ Win32 API.
C# and .NET are actually built on top of the Win32 API. To access some of the advanced features of Win32 that aren't exposed through C# and .NET you use Pinvoke to manually expose a C Win32 function to your C# app.