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 factors indicate that a project's solution should not be coded in a dynamic language?
Familiarity and willingness of the programmers to work with the language.
Your dynamic language is probably my static language.
System level development is a key group of software that typically shouldn't be in dynamic languages. (drivers, kernel level stuff, etc).
Basically anything that needs to have every ounce of performance or low level hardware access, should be in a lower level language.
Another indicator is if it is highly number crunching, like scientific data number crunching. That is, if it needs to run fast and do number crunching.
I think a common theme is processor intensive problems... in which case you will easily see the performance differences, and you will find that the dynamic language just can't give you the power to use the hardware effectively.
That said, if you are doing processor intensive work and you don't mind the hit in performance, then you could still potentially use a dynamic language.
Update:
Note that for number crunching, I mean really long running number crunching in scientific arena where the process is running for hours or days... in this case a 2x performance gain is GINORMOUS... if it is on a much smaller scale, then dynamic languages could still be of use.
To a large degree, programming language is a style choice. Use the language you want to use and you'll be maximally productive and happy. If for some reason that's not possible, then hopefully your ultimate decision will be based on something meaningful, like a platform you have to run against or real, empirical performance numbers, rather than someone else's arbitrary style choice.
Video card device drivers
Speed is typically the primary answer. Though this is becoming less of an issue these days.
when speed is crucial. Dynamic languages are getting faster, but still not close to the performance of what a compiled language is.
Interop is absolutely possible with dynamic languages. (remember classic visual basic, which has "lazy binding"?) It requires the COM component to be compiled with some extras though for helping their callers to call by name.
I don't think that number crunching has to be statically compiled, most often it is a matter of how you solve. Matlab is a good example made for number crunching, and it has a non-compiled language. Matlab, however, has a very specific runtime for numbers and matrices.
I believe you should always opt for statically-typed language where possible. I'm not saying C# or Java have good static systems but C# is getting close. Good type inference is the key because it will give you benefits seen in dynamic languages while still giving you security and features of statically-typed ones. Problem solved - no more flamewars.
System level code for embedded systems. A possible problem is that dynamic languages sometimes hide the performance implications of a single easy looking statement.
Like say this Perl statement:
#contents = <FILE>;
If FILE is a few megabytes, then that is one resource-consuming statement - you might exhaust your heap, or cause a watchdog timeout, or generally slow down the response of the embedded system.
If you want to "program closer to the metal", you probably want to be using a statically typed and "middle level" language.
How about interop? Is it possible to call a COM component from Ruby or Python?
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
At university I majored in compiler theory and grammars, so have a good background in this area (although a long time ago) and know that the creation of a compiler is an enormous major undertaking, at least for a language such as C++.
So I'm confused as to the large number of programming languages that seem to have been created by individuals as opposed to large groups of people working at a company. Ruby for example, according to Wikipedia it was created by one person - I don't know the language perhaps it's incredibly simple, but my point is there are bucket loads of self-created languages out there.
So how does one go about creating their own language (which isn't too simple as to be pretty useless) as an individual and not spend one's entire life doing so?
Are there any good books on the subject (not on compilers and in general, spec)?
(although a long time ago) and know that the creation of a compiler is an enormous major undertaking, at least for a language such as C++.
A lot of things have conspired to make things easier:
Computers have a lot more RAM and speed. Much of the challenge of writing early compilers was being able to do so efficiently and with a minimum of memory. That's why C can compile in a single pass: at the time, you may not have had enough memory to even fit an entire source file in it. Where before a lot of the magic of compiler-writing was optimizing your symbol table representation and parsing as fast as physically possible, now you can get by doing things much simpler and easier.
Base technology has gotten better. Most languages have nice easy to use parser libraries, high-level data structures (symbol tables are a snap if you already have a nice hashtable implementation!) and other tools to make getting a compiler or interpreter up and running much easier.
GC is ubiquitous. Most new languages being created today are garbage collected. That makes it easier to design the language (you don't have to specify detailed memory semantics). At the same time, you can target some existing GC platform like the CLR or the JVM so as the language author, you don't have to write your own GC. In fact, targeting the CLR or JVM makes your job as a compiler writer much easier in general: as a higher-level platform, the bytecode meets you halfway.
Most new languages are dynamically-typed. The majority of new languages being created are dynamically typed. Those are much easier to design and implement. I've found that a majority of the challenge in language design is designing a type system. Likewise, compiling or interpreting a static language is more of a challenge. Dynamic languages where everything is just a property bag are surprisingly easy to get up and running.
Again, computers have a lot more RAM and speed. Back in the day, if your language was to have any chance of success, it needed to compile down to efficient machine code, use memory efficiently and run fast. Otherwise it would be unusably slow. Now that computers are so much faster, even a slow language like Ruby is still fast enough for many real uses. As a compiler writer you don't need as much optimization skill as you used to.
It's also worth noting that no one is making a new language as complex as C++ these days. C++ really is near the top end of language complexity.
I have gone a little way down the route of creating my own language. I started off doing this to represent requirements, analysis and design constructs, rather than a code compiler. For this purpose even a very simple language can be useful. I found it valuable to be able to read and write such constructs in a very constrained version of English - template sentences mainly. Then it became useful to have the language machine readable and so I constructed lexers and parsers to read the language using Lex and Yacc. As I have gone I have expanded the language and its parsers to deal with the expansions.
I am aware that this is a very long way from a robust compiler for a language as extensive as C++, but illustrates one motivation for going down this route. I would suggest that your view of simple languages as being pretty useless is an overstatement. Even a very limited language can be of substantial use.
Though I have basically no experience in making languages of my own, I do have a good amount of experience learning new ones, so I could suggest this -
The programming industry is a marketplace of languages. Languages rise and fall in popularity based on their simplicity to learn and use, lack of commercial and legal restriction, applicability to real-life situations, flexibility, and power. If you want your language to be popular one day, try to go for these.
If you're designing a toy language for its own sake (as many computer scientists do), it's a interesting theoretical exercise and still quite valid, but you might not expect it to become quite as widespread.
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 an intermediate programmer, and have decided to learn either common lisp or scheme. My question is simple, which one would you choose? I don't care much for the difficulty of the syntax, just the power, flexibility, and other aspects of the language itself. Also, which implementation of either common lisp or scheme should I choose? Thanks!
Like so many things, it depends on what you want to do.
Remember, if you choose one now, it doesn't preclude you from changing later. In fact, I found it quite easy to switch from knowing a little Scheme to learning a lot of Clojure.
If you just want to learn, and play around with a Lisp, or even build moderately complex programs, I'd say Scheme is probably a better bet. It's got a cleaner, crisper (smaller) standard library, and there are a lot of resources out that that cater to the learner (not that there aren't for CL, either).
If you want the raw power of tons of libraries (many very well written) and the toolkit of a standard (as standard as a CL implementation gets) library that comes with a CL, then it'd be your better bet.
Alternatively, I'd suggest Clojure. It's a relatively new language (< 5 years), but it's got a lot going for it. It's built for concurrency, with plenty of primitives that make it easy to write state-safe programs if you need to have state. And plenty of other perks, though again, the standard library manages to stay small.
It's also on the JVM, so you have access to all the libraries you would if you were using Java, should you need any of them, plus the raw speed that the JVM has to offer is at your fingertips.
However, it is a new language, with a new (but very friendly!) community. If you just want to dip your toes in the pool of Lisp, I'd say Scheme is your best bet. If you want to get things done, my preference and my love is Clojure.
EDIT Honestly, you can't go wrong with any of the three. One may be better depending on what you want to do, and I'd recommend Clojure to just about anyone.
If you want to write practical code, and/or you want a good degree of portability from one implementation to another, use Common Lisp. There are eleven implementations currently under active maintenance. See my survey of implementations.
The different implementations have different strengths. If you want a free, open-source one, Clozure Common Lisp (CCL) (not to be confused with "Clojure"!) and Steel Bank Common Lisp (SBCL) are good general-purpose implementations. There are also commercial implementations, the best known being Allegro Common Lisp and LispWorks. For Windows-friendliness, Corman Common Lisp has useful facilities. For embedding, Embedded Common Lisp (ECL) is great (you don't have to use it in an embedded way). If you want a Common Lisp that compiles to the Java Virtual Machine, there's Armed Bear Common Lisp (ABCL). See the paper for others; which one you want depends on your individual circumstances.
If you want power and flexibility you go with Common Lisp.
If you want clean and simple you go with Scheme.
So far I'm happy with SBCL.
This is an old one ;) Emacs or vi? KDE or Gnome? Red or White?
The biggest difference between the two is that Scheme tends to focus on functional programming; some authors stress functional programming in Common Lisp, such as Paul Graham, and if I write Common Lisp, I follow their advice.
I tend to prefer Scheme since it just makes more sense to me. I've found that the Scheme community, particularly surrounding free software implementations, is much more focused on free software. Consider that if it's important to you. Contrary to popular belief, Common Lisp is a very popular language, but it's most behind closed, corporate doors. That was a big factor for me to turn away from Common Lisp: when the community's not as open, you're not going to find as much in the way of help and libraries.
As far as implementations, I would recommend Guile if you're a GNU/Linux user. Other implementations are just too far outside the mainstream of GNU-consciousness; I like the GNU community, so Guile was the best choice for me. Also Guile has the best set of libraries included in the default installation that I've found (considering that different from the other respondents I know nothing about Clojure).
I've seen some other respondents repeating the old incantation "If you want to get something done, use Common Lisp; if you want to learn, use Scheme." That was probably true in the era of SICP, but I don't think it's true these days. A good implementation of Scheme, like Guile, has tons of libraries available and has plenty of good use-cases that show you can get plenty of stuff done with it.
My impression: Common Lisp is more for getting stuff done, Scheme is more for education and fun. I prefer the SBCL implementation. Scheme, I don't know.
I have an affinity for the more pragmatic, baroque, and warty programming languages, so I selected Common Lisp.
I use GNU clisp, but I am considering changing to SBCL due to its focus on efficiency.
I chose Scheme because it was the language taught in Structure and Interpretation of Computer Programs. It's been a fun read so far.
I usually view it like this: Common Lisp is to Scheme as C++ is to Python. With both Common Lisp and C++, you're given a huge load of tools and lots of power and essentially allowed to roam free. With Scheme, on the other hand, there's more of a focus on simplicity and you're given a little bit less rope to hang yourself by.
And just like with C++ vs. Python, there's this idea that one is for real, grownup projects while the other is sort of a toy language to play around with or create throwaway scripts, even though in most cases the "toy" is good enough for whatever you need to do.
If you want to look at Scheme, I recommend PLT Racket. It's not strictly standard Scheme, but it's essentially the same and it's a "batteries included" distribution.
common lisp is a lot more useful, but scheme is a lot cleaner. mostly comes down to that.
Scheme is of equal or greater power of Common Lisp, but it doesn't have as much support or bindings. I'd go with Common Lisp. As for the implementation? I've been using sbcl in slime/swank for awhile now, and it's pretty nice and fast. Slime is really nice.
I don't care much for the difficulty of the syntax, just the power, flexibility, and other aspects of the language itself.
The syntax is equally difficult or not in any lisp. Clojure's syntax is a bit easier for non-lispers because different brackets are used. This makes more of a difference than one would expect.
Both Clojure and CL have excellent introductory books. I haven't read scheme books in any depth, but they seem to have a more academic flavor in comparison.
I would recommend Clojure or Common Lisp to a neophyte, based on personal experience.
Clojure is more functional and eminently practical. If using CL I recommend an IDE (Allegro & others have free versions), or using a text-editor and repl. In other words, don't use slime. For Clojure I can't think of any IDEs, but perhaps Textmate or Eclipse will have something?
Scheme has some very good IDEs too such as DrScheme. But I found it easier to stay engaged when doing somewhat of a real project, and both Clojure and CL seemed to make that easier.
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 thinking learn a more low level language like C, but before it i'd like some opnion about:
what's the second language do you recommend to learn?
learn a low level language will make me a better programmer?
it's really necessary learn a second programming language?
Going backwards:
(3) Absolutely - you'll increase your ability by orders of magnitude by learning multiple languages.
(2) A low level language will make you a better programmer - alternatively a functional language will help as well.
(1) Low-level: go with C. Functional, try Scheme or Haskell. C also gives you the ability to write extension modules to Python if you ever have the need.
what's the second language do you recommend to learn?
Something imperative (i.e. same paradigm) but different. Python is dynamically typed with significant whitespace, so something statically types without significant whitespace: e.g. Java or C#.
These would also make a nice stepping stone towards C. The benefit of C is you really know what's going on, but with the disadvantage that you have to control it all. This level of control is not need for most business problems.
it's really necessary learn a second programming language?
Really subjective, but most good developers know many (consider for a web app: Python, Ruby, C#, Java on the server; SQL on the database and JavaScript on the client; and then the mark-up...).
You benefit from being able to see other approaches to problems and thus create better solutions. So once you have covered more imperative languages move into other paradigms like functional.
I agree with your choice of C, which leads on to C++. If nothing else, learning C will teach you why people these days tend to prefer languages with automatic memory management - but it will potentially also give you a feeling of programming "close to the metal" (without the pain of programming in assembly language), and help you to understand how a processor actually works. Not always useful knowledge but it's nice to know.
Whatever you choose, I recommend a statically-typed language - C, C++, Java, and some functional programming languages fit this bill. Java might be a good choice if you find C a bit tough at first.
I'd say learning any new language makes you a better programmer. However, will learning C make you a better Python programmer? Probably not; why should it?!
Define "necessary"! By a strict definition, no. But you're missing out on the experience of having to think about things in a different way (even if it's only a slightly different way).
I would stay with the same paradigm, but leave options open for another paradigm (functional programming). Probably C# is a good choice, because
If you decide to learn C/C++ later, it'll become a bit easier.
If you decide you want to learn functional programming later, you can switch to F# but still use existing code written in C#, because you stay within .NET framework.
Python is not known to be a remarkably fast language. You should consider learning a language which allows better computational performance. But good old ANSI C is probably too low level, despite you can write very fast programs with it. C# has OK performance for a just-in-time compiled language, and if you need more performance later, you can still extend your knowledge towards F# or C.
Although I don't use Microsoft Windows privately and advertise Linux and Open Source frequently, it's probably a good idea to offer some knowledge about Microsoft technology in case you intent to earn money with programming.
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.
Using a factor or forth, Arc or whatever as an example (note: factor is a bad example because it has a large set of practical libraries). Lets say you are considering using a programming language. Does having a large set of practical libraries matter? If your language is well designed, then it would be easy to create a 'string' library or a 'date' library. Maybe even a web framework?
I mention this, because when a language emerges, it seems that someone brings up 'practical libraries'.
It definitely matters - nine times out of ten, I'm going to pick a language with good, well-supported libraries that help accomplish what I want to do.
This isn't to say I wouldn't enjoy writing my own libraries (quite the contrary), but for a production project where quick, accurate results are important, that wouldn't be a practical option by any stretch of the imagination.
Java and .Net have spoiled people with the abundance of classes in the framework or in additional high-quality libraries (quite often free and open source as well). Same goes for Ruby and Python. It'd be hard to adopt a new language without such a library, as your productivity will suffer teremndously by having to reimplement every single feature you need.
Unless it's a breakthrough language that introduces something radical like intentional programming (I tell the computer what I want it to do and it inferes the proper code to do it)... Why, you have one of those? :-)
Practical libraries are important. I don't get paid to write a framework, I get paid to add value to a business. If I told a client I had to charge them to write a string data type, I'd probally lose my job / contract.
Just look at the majority of questions here on SO to see how important tools are to people.
That said, if you find a new language that fits your task really well and you have the time and inclination to write your own tools then by all means dive in. That's one way that new languages get nice libraries, after all.
A large library makes a language much more productive to use. A really great language without support for parsing XML, crypto, a web framework, a UI framework, etc. takes a lot more time to produce working code with. For learning purposes, a language without a large library is fine, but for practical purposes, it is going to cost time and money to use such a language. Imagine if every time you wanted to load an image you had to write code to parse the .jpg headers. What if you had to hand-code your XML parser rather than loading it into a pre-built one. You'd likely screw it up and spend a lot of time debugging. If the goal of the project is to create a new tool, writing support code is not a great use of your time.
I think that the big reason for Python's popularity is its huge standard library. Same goes with Java and PHP. In fact, I'd probably say that the selection of libraries is more important than the language itself.
If your top priority is to create a finished product with the least amount of time and effort possible, then yes, having available libraries matters. (If your goal is fun, or learning for the sake of learning, then writing your own libraries can be a good experience.)
A good library is mature enough that lots of people have used it and weeded out most of the bugs. It doesn't matter how great your programming language is or how easy it is to write a library from scratch. There's no replacement for having your code tested over time.
A lot of libraries are not interesting or fun to write, and reimplementing them again is not going to revolutionize the world in any way. There is only so much you can do with a date library or a string library whatever. It either works or it doesn't. Many libraries are simply an implementation of a standard or of some de facto standard behavior, and someone just has to slog through the necessary work to get it right. The less of this you have to do yourself, the better.
Any brand new language that can take advantage of existing libraries starts off way ahead, in my opinion. Clojure for example, though a very new language, also has access to all the libraries of Java. This is arguably one big reason it's doing so well at the moment. Effort is put toward novel things rather than re-inventing wheels.
You think string libraries are easy to write? Go have a look at Unicode, UTF-8, UTF-16, legacy codepages, byte order issues and whatnot.
You think date/time libraries are easy to write? Go have a look at leap seconds, week numbering schemes and whatnot.
Having these kinds of things thought out for you, implemented once and implemented properly, saves more time and headaches than you think.
It's a tempting idea, and it certainly works if you're Paul Graham or Chuck Moore.
It might work if your domain is very very bounded, and you're not going to get a requirement thrown at you that's outside that domain, something as simple as a client asking for an "import from Excel" feature. On the other hand, Paul Graham used Lisp to write a web shop system, which is a very broad domain of requirements; I'd be interested in knowing how he handled something like a PDF export, would he have given the PDF spec and a Lisp manual to some intern on summer vacation from MIT, or would he have gone down to the C libraries?
It might work if your domain is driven by logic or by enduring natural principles, something like an astronomy simulation. If they're human requirements, they'll be full of contradictions and special cases (string and date libraries fall into that category, by the way), and there is no abstraction or language feature that entirely cuts through that, you'll have to slog through the special cases whether you're writing in Haskell or PHP.
It might work where optimisation is very very important (EDIT: and where you're smart enough to optimise it yourself) - you have a stripped down system where you know every layer of the stack because you've implemented it yourself with a particular goal in mind.
I associate the whole cluster of ideas with grad students: they're in the top 1% in programming skills and general smartness; they're working in a very narrow domain; they may not have the best equipment so they're trying to strip things down and optimise in depth; and they don't have the learning vs getting work done dilemma of working programmers.
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.
Okay, so far, I have been taking computer science courses in my high school and doing some of my own research on the web, and I have found I really like the subject. However, the computer science courses, having given me a small amount of experience in a few languages (C++, java, and python), leave me wondering where to go for development on my own.
I would like to create desktop applications, or even web applications if I could wrap my head around it. What language would you think would best facilitate this?
As a side-note, what are some good books or online documents that explain general computer science topics? I have found some good ones, but they haven't given me the depth I really want.What are some good ones?
Find an "itch"--a program you wish existed, that would be useful for you to have, but you can't find (or costs money). Then try writing it, using online resources (like Stack Overflow) to help you.
At this stage in your career, language doesn't matter very much. Some languages are better than others at certain tasks, but often your own level of comfort with the language outweighs other issues. So just pick a language you're interested in, and a project you're interested in, and get to work.
You may find that you need to start with a simpler project, or you may find more resources for a different language or framework. But getting started with something--no matter what that something is--is probably the most important thing.
Here is a classic but still quite relevant book if you ever want to level up from coder to software engineer.
Since you're still in high school, I would tell you that time is on your side. You have plenty of time to develop as a computer scientist. Therefore, take the long view for your development. So it's much better for you to understand the abstractions that underly software technology.
In my humble opinion, C++ and Java will always be around and you have plenty of time to develop your skills in that arena. However, a higher level language like Scheme or Python will pay plenty of dividends. You might find this recommendation highly enlightening.
In addition, every application will deal with a database as its system of record. Understanding SQL and data modeling is a win-win.
Also, understanding formal logic and/or discrete mathematics is indispensable for computer science. Computer languages are nothing but formal languages for executing
procedures: i.e. mathematical induction is used to define their syntax and semantics.
It sounds like you would enjoy jumping into a high level, modern language that's native to the operating system you want to target; Objective-C or C# for example. On the other hand if you really want to do something for the web, building a web app isn't much harder (there are just more choices to pick from for the back end and front end technologies you decide to use).
Basically, decide what project you want to work on and choose the best language for it. What really matters is that you're working on something.
What language to further develop in?
Given that you know C++, Java, and Python already, a next language I might suggest would be SQL and DDL: defining databases, and getting data in and out of them.
If your CS course didn't touch on it, I highly advise spending a bit of time with a more functional style of language like erlang, haskell or even lisp.
They won't become your day-to-day hacking language overnight, but can really help you grasp important programming concepts relavent accross all languages.
....especially the one about choosing the right language for the task at hand.