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 12 years ago.
Can somebody point out the advantages of Clojure and what type of applications is it suited for ?
I don't intend to compare it to any languages as such. As a language in itself what is it suitable for ? My intention is to know the right tools for the right job, and where does clojure fit-in in that kind of scenario.
Advantages:
all the benefits of functional programming, without the purity straitjacket
lispy: allows dynamic, compact code with late binding, macros, multimethods
Java interoperability
can code functions to sequence abstraction instead of to specific data structures
concurrency goodies baked in: functional data structures, software transactional memory
runs on the JVM: portability and fast garbage collection
Suited for:
bottom-up design
embedded languages
highly-concurrent applications
Probably not suited for:
cases where you want static typing
if you want the language to be amenable to static analysis
anything that needs a fast startup time
hordes of clueless Java monkeys
In general I find as strong points for clojure (in no particular order):
1) The REPL to try things out interactively.
2) Everything is immutable by default and mutability has several well chosen standard patterns to modify state in a safe way in an multithreaded environment
3) Tail recursion is made explicit. Till there is proper support for tail recursion on the JVM this is probably the best compromise
4) Very expressive language which favors a functional approach over an imperative approach.
5) Very good integration with the Java platform making it painless to mix in Java libraries
6) Leiningen as a build and dependency management tool together with the clojars site
Ok, point 6 has nothing to do with the language perse, but definitely with my enjoyment of using it.
Regarding applications it targets multithreading applications, but the way things go right now that could mean about anything, as everywhere people try to keep all those cores busy while the user is not waiting. On the other hand apparently a lot of people use it to deploy to Google App Engine which is radically SINGLE threaded.
The functional approach works well in my (limited) experience for implementing data transformations and calculations. Where information and events can be 'streamed' through the application. Web apps fall largely under this category where we "transform" a request into a "response".
But I still have to use it in real production code. Currently I use it for personal projects and prototyping/benchmarking stuff.
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 9 years ago.
I am building a C# project. This project is going to use NVidia's Tesla through CUDA. CUDA C native implementation is not exposed directly to C# and, in my opinion, the available C# wrappers (like Brahma, CUDAfy, Linq to GPU) are not mature enough for production.
I decided to go ahead and build my math logic in a C++ component that is going to access CUDA which is the official supported way. C++/CLI is not an option as I am using Intel C++ Compiler, for performance, which doesn't support CLR extensions.
My most important criteria is performance, so, I would try to minimise marshalling and copying arrays between C++ (where my business logic lives) and .NET (the rest of my applications).
I am aware that this question has been asked before, but mostly, the C++ library is already there and other times, C++/CLI is an option, but here, both situations are not the case.
Given that I am going to write the C++ library from scratch in C++, I am in the position to decide the best way to expose it to C#. Do you have any recommendations or best practices that I should follow to get the easiest and highest performing integration between C++ and .NET? Note that what I will be exchanging are mostly large arrays
Edit: clarifying that I am building my business logic (math) in C++ and not an infrastructure library to facilitate access to GPU.
While it is certainly possible to outperform the already existing libraries that you deemed not mature enough, the very fact that you are asking this question here should make you think twice about deciding to roll your own library/implementation!
Considerations beyond specific performance such as stability and reliability should be your primary concern if this is going to production. Generally unless you know what you're doing, duplicating the effort of the community, or other teams of developers, can be a slippery slope.
I know this answer doesn't really address your question but as it's formulated your question is in my opinion overly broad and there is no simple answer. Initially I was going to post this as a comment but decided it was too long to fit the format.
So, in closing, I recommend you try out the already existing libraries and if you find them not-fitting from a performance stand point, start asking specific questions.
UPDATE
If you're going to implement most of the logic in C++ and you're expecting to just be transferring some results back to your managed code in the form of arrays then there isn't much that you need to do. In general the automatic marshalling of arrays is as efficient as you're going to get.
The one thing I would recommend is though to read as much as possible about Marshalling and use a performance profiler before deciding to get "creative" in order to improve things.
And here's one last idea that might be interesting but again, you should profile before attempting to use this: you might try to use a Memory Mapped File as the backing store for your data and open the file from both ends. Ultimately this may or may not be useful so definitely profile before you buy ;)
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 was recently working on a Web Service Project and realized my choice of architecture was extremely inefficient.
I wrote this in a very procedural manner with a hint of OOP and standard Exception Handling using Python. Basically, it would procedurally step through the data, validate existence of expected data, validate the data against a regular expression, validate some data against a database, perform some specific logic, check for errors, and then finally return a response. It might be helpful to mention that all data was exchanged using JSON.
I tried to go back through the code, find any duplicated exceptions, and push their handling to the top of the logic chain. This was not as easy to do as I had hoped and actually cost more time. It also made my code more prone to bugs by being less Unit Testable and harder to read.
I've noticed this paradigm of procedural code for handling User Data is very easy to fall in to with Web Development. For example, while handling a Form in PHP one may run a consecutive series of isset() and !empty() methods on the data. My problem with this coding style is that I feel like I'm spending an enormous amount of time coding for Error Events and it's difficult to generalize and re-use code for this particular purpose.
Various frameworks offer great ways around this through the use of Form Classes (e.g. Django). However, I have noticed that while you save time by reducing the duplication of Validation Logic, you will still need to "build" a Form for each expected input. When dealing with Software as a Service, there can be potentially hundreds of API Methods that you must code for. OOP offers a benefit here but there are times where a client may set an odd requirement which removes any efficiency gained.
Web Applications can benefit greatly from following paradigms/architectures such as MVC. In my personal experience, MVC (and the frameworks which use its principles) are not well tailored to this type of problem. I've considered the use of Functional Languages but have yet to give them a try.
Are there any particular languages, architectures/paradigms, conventions, or even example frameworks that are well suited for the development of custom SASS or Web Service Projects?
As someone who does a lot of this work, I would say that part of your problem with OOP and PHP is caused because initially PHP was not an OOP language. OOP was added to the language later on. So when you look at code examples they often can have a procedural feel.
In recent years I've been most happy with either Spring (Java) or WCF (C#). Both these languages are strongly typed OO languages. From a conceptual standpoint this leads to a paradigm that works well for my projects. Here's the overview:
Endpoints (Either REST or WSDL) -- similar to view in MVC
Services -- These feed the endpoints and coordinate DAOs as needed. Organize these around your business logic
Data Access Objects -- convert data into native objects and vice versa. Organize these around your data sources.
Model / API -- Native Objects to support application and automatically provide documentation for your service.
Hope that helps
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 12 years ago.
Why should I choose Clojure over another language for a new project? In what areas does it excel?
Some scenarios where I would use Clojure:
You are building a new, highly concurrent application that needs to scale reliably. In my opinion, Clojure's concurrency features (STM, immutability-by-default, lock free MVCC) are the best of any major language at present. Rick Hickey's excellent video about Identity and State is a great way to get a feeling for this.
You are a Java-based shop that wants a productive dynamic language that can be used for rapid development or scripting while maintaining your investment in a large Java code base. I've found Clojure pretty effective at "gluing together" Java code since the interop capabilities are extremely good (and simple!).
If you want to use a functional programming language Clojure is pretty good (it's not quite as "pure" as Haskell but has all the key features - first class functions, higher order function composition, immutability, laziness)
If you work in a field where there is a major need for code manipulation (compilers, DSLs, natural language processing, genetic programming), where the LISP "code is data" philosophy enables you to be extremely productive. This is a sweet spot for homoiconic LISP based languages in general.
At the risk of providing exactly the sort of reductive non-answer that Devin is referring to: I chose Clojure because I like the functional programming style and Clojure lets me do that on the JVM and interop with lots of existing code that runs on the JVM.
So the question then becomes: Why functional programming?
Immutable state - lack of side-effects, easier testing, better support for concurrency (and, in future, parallelism).
Small, functional components that can be easily reused and composed to construct large, flexible systems.
it's very hard to find clojure developers so I would stay away from it if you work for a big company and stick with java or .net. it's more a political than technical decision in large companies. if however you are building your own product then clojure is very fast to develop in and can get you to market faster.
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 a C++ / Linux Developer till now and I am adept in this stack. Of late I have been getting opportunities that require Perl, Unix (with knowledge of C++,shell scripting) expertise. Organizations are showing interest even though I don't have much scripting experience to boast off. The role is more in a Support, maintenance project involving SQL as well. Off late I am in a fix whether to forgo these offers or not.
I don't know the dynamics of an IT organization and thus on one hand I fear that my C++ experience will be nullified and on the positive side I am getting to work on a new technology stack which will only add to my skill set.
I am sure, most of you at some point of time have encountered such dilemmas and would have taken some decision.
I want you to share your perspectives
on such a scenario where a person is
required to change his/her technology
stack when changing his/her job.
What are the merits and demerits in
going with either of the choices?
Also I know that C++ isn't going
anywhere in the near future. What
about perl? I have no clue as to what
the future holds for perl developer?
Whether there are enough
opportunities for a perl developer?
I am asking this question here because most of my fellow programmers face this career choice dilemma.
EDIT:
Since the last time I asked this question, I made up my mind to switch.
I was just about to sign on the dotted line but some divine intervention made me seek some clarification about the working hours, and to my horror, the profile required me to work in
shifts which I am never comfortable with. I was all the more livid because they didn't clarify this point earlier. It was a reputed organisation but still I gave them my piece of mind and said thank you very much.
Thanks.
Regarding changing of stack, it definitely helps you long term in your career, both from extra experience available to offer to next employer to expanded job set you can qualify for to increased programming IQ due to knowing different points of view (e.g. Perl, for all its scripting origins, when used properly, has both OO and very nice functional paradigms available, but this point applies to any new technology).
However, you must be willing to put extra effort in to actually learn new stack/environment/language, and to learn to do things new way (e.g. don't write C++ code in Perl :) - especially for that last benefit to kick in. Please note "environment" there - the jump involves for example learning new debuggers and debugging techniques (for me the hardest thing about C++ development after switching from Perl so far is probably doing effective gdb debugging after being used to flexibility/power of perl debugger).
Personally I had to make this jump twice - from C developer to Perl and 10 years later Perl to C++. I learned a lot both times, and am not sorry I made the jump. The first jump was from IT role (Junior SA/Production with some C coding) to a full-on developer, the second was just a jump between different business teams.
As for demerits, please be aware that you WILL lose your edge in whichever stack you're not currently using for a while. Not completely forget, but nowhere near where you left off - and that does not even count the fact that the stack may have naturally evolved in the time elapsed. Also, as I said, you MUST expect that to be effective, you have to put in a lot of effort to become fluent in idiomatics, philosophy and ecosystem of the new stack. E.g. simply learning Perl is a small piece of the puzzle - you need to become familiar with a large chunk of CPAN, just as you had to know STL etc... Not really a demerit as far as I'm concerned, but a point that needs to be kept in mind.
As for opportunities for Perl developer, this was extensively covered on SO before. While the absolute # of jobs is likely less than that of Java or C++ ones, a high quality developer will always be in demand, and there's plenty of companies (including, or may be especially, in financial industry) heavily using serious Perl development (as opposed to simple administrative scripting). The language itself is developing and moving forward as well.
This is a highly subjective question. Whether C++ is "going places" depends on where you look and who you ask. For instance, C++ is the development language for video games and graphics processing, and is also used a lot in device drivers in conjunction with C (usually I see a hybrid "C+-", where some features are used from C++ in conjunction with more C-style architecture).
I myself moved from a C/C++ environment into a mostly Perl one, with strong Unix all the while (I actually know next to no windows API programming, .NET, VB-Basic etc).
Basically what I would suggest is sticking with what you enjoy most. This may not be the same as what you currently know or are best at. There are opportunities in a diverse set of technologies. Don't also assume you should tie yourself to one environment -- dabble a little and have some fun. Many facets of programming are constant across languages and environments. Get good at problem solving, writing unit tests, refactoring and planning a project, and you'll do well no matter what set of technologies you're working with.
Why not use your C++ expertise when working with Perl (where appropriate)? It's quite possible to extend Perl with C and C++. I'm not suggesting that you write all your code in C++ just because you know it and than put a thin Perl layer on top, of course.
Being experienced in related technologies is a really big advantage, not a mis-qualification for a technical job. I would suggest you take the opportunity to learn a new technology. Going back from "experienced but rusty" to "on top of it" in your bread-and-butter discipline should be a piece of cake if you have to at a later point in time.
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.
As a C++ stickler, this has really been bugging me. I've always liked the idea of the "language-independant framework" that Microsoft came up with roughly a decade ago. Why have they dropped the ball on this idea? Does anyone know the reasoning behind it?
Part of the reason will be that C++ support is actually two languages in one -- the native and the CLI variants; that extra development load has been acknowledged by the Visual C++ team as the reason that proper MSBuild integration lagged (lags? I haven't checked in 2008 or later) behind other languages.
Another part will be to do with the code generation during compilation that goes on in a C# build to support e.g. the binding "magic"; I've found that even in F#, you don't get it "just happening".
If it were me my reasoning would be that C++.Net should not be used to write GUIs.
I'm not trying to be snarky here, maybe someone can show me the error of my ways but I don't think it's a good idea. I'm messing around with one right now and development much much slower than if the application had been written in C#. My feeling is if features in C++.Net or just regular C++ are required for the application it seems like a better idea would be to create a DLL to do the heavy lifting and could interface with C#.
It bugs me too, if they had supported it, we'd be able to migrate our C++ code to a new GUI much easier and cheaper than basically rewriting everything in C#. Its costing us a fortune to rework our apps, just what we wanted in a recession.
I imagine the reasoning is that C# is popular (and not as cross platform as C++) so they've decided to keep their development efforts to the minimum required.
You can do WPF with managed C++.
The reason is that nearly all new application programming is now done in JavaScript, Java, VB.NET or C# - all GC languages. The emphasis is on higher quality for a lower skill set and C++ demands too much from the developer, companies want people to write log bug code on their first day.
C++ for applications is mainly for maintenance of existing applications or where extreme performance is needed. Device drivers and OS are still frequently written in C++ but even that is changing (Coyotos is Cbit , E# , Cosmos/Mosa are C#, Singularity/Midori).