Jump to content





Recent Status Updates

  • Photo
      16 Apr
    Kadence

    If you're reading this, you're on my profile and I know you're on my profile because I'm probably viewing yours.

    Show comments (6)
  • Photo
      10 Apr
    Poe

    Finally (and hopefully) i'm getting a team together that knows a little of this and a little of that; and maybe all my open source projects that are half written can begin to be released. :)

View All Updates
Photo
- - - - -

Most Productive Programming Language

lisp prudctive language

24 replies to this topic

#13 Pally

Pally

    CC Addict

  • Senior Member
  • PipPipPipPipPip
  • 393 posts
  • Programming Language:C, Java, PHP, Python, PL/SQL, Assembly
  • Learning:C++, C#, Lisp, Scheme

Posted 07 March 2013 - 07:37 AM

according to the wikki page on F#, its actually a multi-paradigm language; so it can be adapted easily to many situations (i guess.)<br /><br />Still, without thinking about a specific domain of problems its hard to really nail what a productive language is. Some problems lend themselves to functional style, some to OO, some to procedural etc. A language with the best fit to the problem will give you a productivity boost.

Upon further thought into this discussion I think your right, 

‚Äčthe only way to really remain productive is to use a domain specific language that does the job most productively for the task at hand...

When I started this discussion I thought of a general purpose language... I suppose any general purpose language will run into some conflict between various tasks and have trouble creating productive solutions... productive seems conflicting term as well because productive low level manipulation of memory could be your idea of "productivity" one day and tomorrow your idea of productivity may be getting a similar program working even though its sloppy in memory consumption. In both cases your trying to be productive but with separate tasks at hand which conflict with another end goal.

 

 

So ironically this discussion of the most productive language seems to have led to the same outcome the popular "whats the best programming language" topics always lead to.


Edited by Pally, 07 March 2013 - 07:37 AM.

  • 0
Your Friendly Neighborhood Pally

#14 LinkChef

LinkChef

    CC Regular

  • Member
  • PipPipPip
  • 47 posts
  • Location:U.S.A.
  • Programming Language:C#
  • Learning:Java, C#, Lua

Posted 13 March 2013 - 06:14 PM

Although I've not been a programmer for a very long time, I did look into programming languages long before I actually programmed.

 

Although my first opinion on the matter is simple, it's one that should be said.  Obviously, the best programming language is the one YOU know the best.  Not surprisingly, you can be super efficient in anything that you know really well when you compare yourself to others.  Plus, if you've written code before that would be handy for the program you have now, you know where that code is, and copy, paste, and adapt into a program.

 

However, if we get rid of that entire idea, although I can't say with experience from other languages, C# with the .NET Framework has to be one of the most efficient out there.  .NET is the entire reason though.  C# in itself is great, and is very good for people familiar with C++ or Java, but .NET framework allows coders to be a tad lazy.  One of the biggest things I've learned is that computers math-wise can only add, subtract, multiply, and divide.  To do powers, or logarithms, etc., you have to be smart with the basic operators and making a method.  That's why we have the Math.Pow() method in .NET.  This takes a lot of time out of the coding when you know you can do more complex operations without working through how to do it with basic operators.

 

Anyway, that's what I've seen, but I've read a few others, and they're all really interesting.  Have a good day everyone!


  • 0

I'm Batman!  ~Batman


#15 WingedPanther

WingedPanther

    A spammer's worst nightmare

  • Moderator
  • 16,633 posts
  • Location:Upstate, South Carolina
  • Programming Language:C, C++, PL/SQL, Delphi/Object Pascal, Pascal, Transact-SQL, Others
  • Learning:Java, C#, PHP, JavaScript, Lisp, Fortran, Haskell, Others

Posted 14 March 2013 - 06:14 AM

LinkChef, I've been looking into ASP.NET recently with MVC 3. It's easy to say it allows a programmer to be lazy, but it also allows a programmer to easily integrate unit testing into the project, practice the discipline of separating logic from display of content, etc. In that sense, .NET can also be said to make it really easy for a programmer to be disciplined. At the same time, I'll be having to think carefully about how to use LINQ with my database queries to optimize the efficiency of my code while maintaining maintainability :)

 

Everything requires balance :)


  • 2
Programming is a branch of mathematics.
My CodeCall Blog | My Personal Blog

#16 mbcev

mbcev

    CC Regular

  • Member
  • PipPipPip
  • 36 posts
  • Location:Scottsdale
  • Programming Language:C, Java, C#, Others
  • Learning:Others

Posted 14 March 2013 - 01:11 PM

I want to throw another point in for LISP's. I've spent quite some time now learning Clojure to augment my usual Java tomfooolery and I have to say that after some practice I've been finding myself able to write more with less. But before I get into that:

I've played with C, C++, C#, JavaScript, Racket, Python, heck even MIPS and x86 for a time too. The biggest reason I stuck with Java over adopting any of those alternatives (except where specific situations warranted their use, and in fact my first language was C so I still hold a soft spot in my heart for it) was specifically because they didn't improve my productivity at all. In fact they slowed me down simply because I didn't know the standard libraries. Although I don't believe this truly counts as a legitimate "slow down" because if I were more experienced in any of those other options then I wouldn't be any slower with them than I would be with Java (except maybe the assembly languages :-P). 

 

I mean I could write up my own instances of the data structures I needed, or parsing libraries, networking and io libraries too, but it kind of defeats the purpose of having "standard libraries" right? And since I have become very familiar with Java and it's countless libraries, why spend the brain power hacking away in those other languages? My problem solving methodology remains entirely unchanged so 90% of the time, the code I wrote in one language I could almost completely transcribe into another (this is especially true with Java and C# because even their syntax and choice of keywords is almost identical haha). As far as this family of languages is concerned, my opinion pretty much is that you're going to be the most productive in the language with the most tools for you to be productive with (read: lazy). Typically this is going to mean "who's got the most useful libraries for me to take advantage of". 

 

Back to Clojure; what's so special about it? For those who may recall my frustration with the language when I originally picked it up, it was worth the headaches and here's why:

 

Languages, both computer and human/linguistic, as well as Mathematics are ways of expressing human thought. Human languages specifically allow us to transmit ideas to one another in very complex and abstract ways which can be difficult to express in terms of Computer Languages or Mathematics. One of the issues with Human languages though is that they're rather static. You generally can't take expressive shortcuts like say recursion in CS/Math. This is where Mathematics has come in. Ultimately mathematics is very much just the short hand abbreviations for what was once written out in sentence form. There are more shortcuts that you can take to encompass wider sets of ideas this is what makes it so useful still today. Next came programming languages which are so immensely powerful in their own right because they allow us to go so far as to automate human thought! You can now string together lines of Mathematical expression, which was already a short hand for spoken languages, in order to produce machines that can just flat out replace a human. The efficiency gains are enormous and we see them every day! Dealing with ATM's is way faster and way cheaper than dealing with human tellers in a brick and mortar bank as a for example.

 

So what does this have to do with LISP's? More specifically Clojure? So I'll admit, LISPs are hard to pick up at first... especially if you've become ingrained in the ways of Declarative and/or Imperative programming (as I most definitely was)... but what makes them special is that they let you do things that you would otherwise have to do "the long way" much like what mathematical symbols did for written word and later programming for mathematics. The more pure functional languages like Common Lisp, Scheme, or Haskell in a sense allow you to automate your automation. This is why LISP's have stuck around for as long as they have, but they do still have there share of problems, which is why they never gained enough traction to ever take over the world. Clojure gets a lot of slack from the "pure" Lisp community for being so middle of the road in terms of "Lisp purity" but I think that's what makes it so much more productive to use. It's flexible. It's got most of the fluff that you have in a "pure" Lisp while still allowing you to escape from those shackles when you need to. I believe this is why Ruby, which was mentioned a few times already) is so popular too. It has a lot of functional programming influence in it but it isn't "pure". Neither Clojure, nor Ruby, are tied down to their religion like Haskell is, lovely a religion though that it may be. Clojure is also convenient because of the interop with Java means I can use libraries when I need/want to instead of writing it myself after finding out another Clojurian hasn't written it for me. And Ruby is popular enough that it doesn't have that much so much anymore (at least I presume so; I can't speak from experience on that one). Basically, you have your productivity gains from libraries/tools that you'd see in any of the other previously listed languages, as well as from the "magic" that is Functional Programming.

 

Long story short: my vote goes to Clojure in terms of productivity. But then, that's just my opinion. To each their own  :thumbup: .


Edited by mbcev, 14 March 2013 - 01:15 PM.

  • 2

#17 redserpent

redserpent

    CC Lurker

  • Just Joined
  • Pip
  • 1 posts
  • Location:Swedesboro,NJ
  • Programming Language:JavaScript, Ruby, Others
  • Learning:Java, C++, PHP, Python, Scheme

Posted 10 February 2014 - 02:24 AM

  I got to this forum because of a Google search on more productive languages.
 Am a nubie programmer. What interests me about Productivity in a language is what languages coded the most products out. In recent years...last 8.   I do understand that my query included a hidden element of 'what is  trending up'.  Appears to me as if languages (their use)  are pigeon-holed to industry  sectors.  Is there a Venn diagram and  what does it look like.
  Maybe a programmer's code working for ASP, BofA, GM,  Procter& Gamble has little intersection with languages used by Companies like Twitter, Yahoo, Bloomberg, Huffington Post, Apple. I don't know.
[a] I like Ruby because gets me to Rails and quickly allows me to work with web development, even as a newbie.
[b] I like JavaScript because of its libraries like jQuery and use with programming  web develpment and AVR's(robotics) Arduino and Raspberry-PI micro-controllers. 
[c] I like C because of AVR's as above. C is really a romantic language and strong heritage,  However producing software in C/C++  ...  looks so difficult to envision a way to monetize App Development, particularly as a self starter.
  In terms of making a living$$ whether is graphics, web dev, , science, payroll, embeded aplications, training material, defense contracting, ....what are the 3 most productive languages now and the next 8 years?

Edited by redserpent, 10 February 2014 - 02:30 AM.

  • 0

#18 Lufuno

Lufuno

    CC Newcomer

  • Member
  • PipPip
  • 12 posts
  • Programming Language:Java, C++, PHP, Python, JavaScript, Perl, Ruby, Assembly, Prolog
  • Learning:PL/SQL

Posted 15 February 2014 - 06:42 AM

I think Scala is quite productive. Compared to Java,C++ & C#. Arguably even more productive than python
  • 0

#19 Chall

Chall

    CC Addict

  • Advanced Member
  • PipPipPipPipPip
  • 296 posts
  • Location:Cedar Rapids, IA
  • Programming Language:Java
  • Learning:C, Java, C++, C#, Python, JavaScript, Assembly

Posted 16 February 2014 - 12:37 PM

Java is mi Favorite. Simply because it does everything I need it to usually. Even now that I got my first phone, since it's an android, I wont have to learn a whole new language. For me, it fits everything I do. Works on Macs, PCs, and Androids. What more could I want?


  • 0
Speaks fluent Java

#20 wim DC

wim DC

    Roar

  • Expert Member
  • PipPipPipPipPipPipPipPip
  • 2,495 posts
  • Programming Language:Java, JavaScript, PL/SQL
  • Learning:Java, PHP

Posted 16 February 2014 - 11:49 PM

What more could I want?

A more concise language :P

Don't get me wrong. I program Java for a living and like doing so. But sometimes I look at Python or something and think "Damn this looks so pretty." ^^
  • 0

#21 gonerogue

gonerogue

    CC Addict

  • Advanced Member
  • PipPipPipPipPip
  • 166 posts

Posted 17 February 2014 - 12:26 AM

I like the simple design of go (http://golang.org/).


Edited by xyv123, 17 February 2014 - 12:28 AM.

  • 0

#22 notchent

notchent

    CC Lurker

  • Just Joined
  • Pip
  • 2 posts

Posted 30 March 2014 - 04:47 AM

My vote is for Rebol.  I've been using it for more than a decade and have never found any other general purpose development tool or language which is more effectively productive or expressive for my needs:  http://learnrebol.com and http://easiestprogramminglanguage.com


  • 0

#23 BlackRabbit

BlackRabbit

    CodeCall Legend

  • Expert Member
  • PipPipPipPipPipPipPipPip
  • 2,952 posts
  • Location:Argentina
  • Programming Language:C, C++, C#, PHP, JavaScript, Transact-SQL, Bash, Others
  • Learning:Java, Others

Posted 30 March 2014 - 10:18 PM

It's odd many coders are rooting for a particular language without even asking:  Most productive for what? And how do you measure that productivity?

 

There's two things to be considered:

If the tool is more important than the coder skills, then coder is a bad one :P

I mean, most things you can program in one lang you can do in other. And once done, you automatize it (like in a library, api, or working methodoloty) and your job will be easy and good. For instance, C++ might have high learning cost in time, but once you capitalize that knowledge into working methodology and your own set of tools, call it your personal framework if you want, then you have it all encapsulated and you will probably go faster than a built-in tool of any other language. (And I am not rooting for c++, just explaining how it works)

 

About productivity, it's mostly about libraries and frameworks than languages, if by productivity you mean make programs with the lesser effort, and that goes for c++ and python the same.

 

So maybe we should resort to "best to produce what", and we will probably end up talking about libraries, and techniques. Languages are not productive, good coders are ;)


  • 2

#24 notchent

notchent

    CC Lurker

  • Just Joined
  • Pip
  • 2 posts

Posted 31 March 2014 - 07:55 AM

It's odd many coders are rooting for a particular language without even asking:  Most productive for what? And how do you measure that productivity?

 

There's two things to be considered:

If the tool is more important than the coder skills, then coder is a bad one :P

I mean, most things you can program in one lang you can do in other. And once done, you automatize it (like in a library, api, or working methodoloty) and your job will be easy and good. For instance, C++ might have high learning cost in time, but once you capitalize that knowledge into working methodology and your own set of tools, call it your personal framework if you want, then you have it all encapsulated and you will probably go faster than a built-in tool of any other language. (And I am not rooting for c++, just explaining how it works)

 

About productivity, it's mostly about libraries and frameworks than languages, if by productivity you mean make programs with the lesser effort, and that goes for c++ and python the same.

 

So maybe we should resort to "best to produce what", and we will probably end up talking about libraries, and techniques. Languages are not productive, good coders are ;)

 

 

This topic is about the "most productive programming language", so commenting about specific languages certainly seems appropriate.  When I started programming back in the 1970s, many people thought that coding in anything but assembly was pointless, and that any developer worth their salt could be just as productive with assembler, given some experience and discipline.  Today, I think most developers would agree that Python, for example, is generally more expressive and capable of producing working code more quickly and efficiently than Assembly, for a wide domain of general work, no matter who the coder is.  The language design of any higher level mainstream language available today is certainly capable of producing end results with less work than was possible in the 1970s, as Assembly was capable of greater productivity than pure machine language in previous generations.  That seems like an effective working definition of "productive".  The language design itself is higher level and more of the end result can be produced with less effort, proportionate to skill.  In the comparison between Python and Assembly, Python loses bare metal control, but there's very little doubt that it gains productivity.  Libraries, frameworks, and all other language tools/methodologies are simply features of the current generation of tools, and thinking that they are the be-all-end-all of language design represents a myopic view of the present state of software development tools.  
 
Five hundred years from now, it's unlikely that tools such as Python, Ruby, Closure, etc. will end up being the best solutions which humanity comes up with in terms of software development productivity.  I'm 100% certain that a comparison between Python and mainstream tools and techniques in the future will make the difference between Python and Assembly seem trivial.  And, believe it or not, there are actually already tools which are working toward the goal of becoming far more expressive than those in the current mainstream.
 
I pointed out Rebol because it's particularly relevant to the topic of "most productive programming language".  Rebol is specifically built from the ground up to enable the creation of DSLs, and from what I've seen, that is a huge step forward from mainstream thought - and it's NOT based on libraries, frameworks, etc.  It's based on the notion that more effective *language design* can be applied to any specific domain problem.  Take a look at http://redmonk.com/d...expressiveness/  .  I'm sure there's a lot of personal bias and preference built into my own viewpoint, but there are clearly many solid metrics, and hoards of empirical evidence which demonstrate that language design, especially something so different as Rebol, actually does provide measurable productivity improvement (and for anyone who's used Rebol, it's obvious what the productivity benefits are.  I think our community actually prefers to keep it a secret).  Rebol's not popular, so I don't expect many people to ever even give it a second look, but from my decade of experience using it, it is far and away more expressive and productive than any other tool I've ever come across, given the same objective viewpoint, abilities, and perspective from one person's consistent point of view .
 
I think looking back at the tools we have available today will be perceived with a perspective similar to the current view of Assembly in the past, even a few decades in the future, because the tools available today - the tools themselves - not the coders, are simply not as evolved, and not as plainly productive.

  • 0





Also tagged with one or more of these keywords: lisp, prudctive, language