Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

"Clinical Trials" For Programming Languages?

samzenpus posted about a year ago | from the apples-and-oranges dept.

Programming 232

theodp writes "High school junior Charles Dawson's New Year resolution is to write a new program in different language each week. It's an ambitious project for someone of any age, and while it won't give him an in-depth appreciation of programming language differences, it'll certainly give him greater insight into the strengths of certain languages than would perusing the Hello World Wikipedia article. Lots of claims are made about the comparative productivity of programming languages, but have there been any landmark studies that measure the efficacy of a programming language's productivity claims in a 'clinical trial' of sorts? Would head-to-head tests against other languages be a better way of sorting out Popularity vs Productivity vs Performance claims, or is relying on more nebulous claims of superiority the best we can do?"

Sorry! There are no comments related to the filter you selected.

All hail Nebulous! (0, Informative)

Anonymous Coward | about a year ago | (#45878911)

Re:All hail Python! (1)

BreakBad (2955249) | about a year ago | (#45879265)

Fixed

That is a beautiful start of a ... (5, Insightful)

Anonymous Coward | about a year ago | (#45878931)

long flamewar

Re:That is a beautiful start of a ... (4, Funny)

Anonymous Coward | about a year ago | (#45879313)

long flamewar

To do this flamewar properly little Charlie Dawson should post his findings every week so we can keep this thing going until he finally realizes his dream of pissing off every programmer.

Re:That is a beautiful start of a ... (4, Insightful)

DuckDodgers (541817) | about a year ago | (#45879351)

It shouldn't be a flame war. In order to make a meaningful comparison between two programming languages I think you need to have a high level of skill in each, and write two feature-equivalent non-trivial programs in each.

Most of the flame wars are between people who don't have good expertise in at least one of the languages under discussion, arguing about merits and drawbacks in simple programs.

I think what Charles Dawnson plans will be interesting, educational, and fun, but you can't become good enough in a language in a week to have a useful opinion on its effectiveness at creating the next social network, operating system kernel, C compiler, web browser, search engine or office suite.

Re:That is a beautiful start of a ... (0)

Anonymous Coward | about a year ago | (#45879747)

It shouldn't be a flame war. In order to make a meaningful comparison between two programming languages I think you need to have a high level of skill in each, and write two feature-equivalent non-trivial programs in each. Most of the flame wars are between people who don't have good expertise in at least one of the languages under discussion, arguing about merits and drawbacks in simple programs. I think what Charles Dawnson plans will be interesting, educational, and fun, but you can't become good enough in a language in a week to have a useful opinion on its effectiveness at creating the next social network, operating system kernel, C compiler, web browser, search engine or office suite.

Says you. If you can't master x86 assembler in half that time, you need a new career.

Re:That is a beautiful start of a ... (2)

DuckDodgers (541817) | about a year ago | (#45879943)

If you can master Haskell, Lisp, Perl, and J in one week each, more power to you. I can't.

Re:That is a beautiful start of a ... (5, Insightful)

brausch (51013) | about a year ago | (#45880149)

The real problem is that different languages are often created to solve different problems. You can't really compare them very easily with any single program, no matter what non-trivial program that you use. For example, C is a better programming language than Javascript for some problems; Javascript might be better than C for some other problems.

I'm advanced to expert in about six languages and have decent experience in a dozen others. I've settled on about four that I use a lot, and that fit the kinds of problems that I work on. Other equally skilled and experienced programmers (programming for over 40 years) would choose a different set of languages better suited to solving the problems they routinely work on.

It's kind of like trying to compare the toolbox of a plumber with the toolbox of a mechanic. There is overlap of course but there are also specialized tools.

Re:That is a beautiful start of a ... (4, Funny)

alex67500 (1609333) | about a year ago | (#45879557)

It's only a flamewar until you agree that there are 2 types of programming languages:
- Those everyone bitches about
- And those nobody uses

Re:C and C++ (1)

Anonymous Coward | about a year ago | (#45880235)

Irony is that marketshare for C and C++ is going down. Rust or Go or D or M# is the future of systems languages!

99 bottles of beer (5, Informative)

jbolden (176878) | about a year ago | (#45879003)

There is already a pretty good collection http://www.99-bottles-of-beer.net/ [99-bottles-of-beer.net]

There is also a website with the implementations of the Perl cookbook in a bunch of languages: http://pleac.sourceforge.net/ [sourceforge.net]

Rosetta Code (0, Redundant)

Anonymous Coward | about a year ago | (#45879267)

http://rosettacode.org/wiki/Rosetta_Code has more than just 99 bottles of beer.

Re:99 bottles of beer (5, Insightful)

Savage-Rabbit (308260) | about a year ago | (#45879525)

There is already a pretty good collection http://www.99-bottles-of-beer.net/ [99-bottles-of-beer.net]

There is also a website with the implementations of the Perl cookbook in a bunch of languages: http://pleac.sourceforge.net/ [sourceforge.net]

Where performance is concerned I'd go for something like the Debian Benchmarks game. The time taken for this benchmark task, by this toy program, with this programming language implementation, with these options, on this computer, with these workloads. With enough people participating in the pissing contest you eventually get things optimized to hell and the wheat is separated from the chaff.

http://benchmarksgame.alioth.debian.org/ [debian.org]
http://benchmarksgame.alioth.debian.org/play.php [debian.org]

As for productivity, that's harder since this is highly subjective. While you can generally postulate that coding in non typed scripting languages where you don't have to worry about memory management is going to be faster than coding in a typed, manually memory managed language like C. But what happens when you compare more similar languages like Python vs. Perl? Your productivity in a language is highly dependent on your experience with it, how fast you are at typing, how intuitive the syntax is to you.... etc... But different programmers can have different issues with languages. In Perl for example the syntactic freedom can actually lead some programmers to write bugs bugs into their code because they are used to languages with a more nailed down syntax.

Re:99 bottles of beer (4, Insightful)

plover (150551) | about a year ago | (#45879721)

Productivity is a tough one, but it's by far the most important. That's what we get paid for.

A good competition might be to start with a functional test, and just let developers "swing away" at it. Or you might add real world constraints that development organizations want to see, such as requiring 95%+ code coverage with unit tests, keeping complexity below 12, and it must pass lint / pmd / fxcop / other static code analysis tool with no warnings or errors. Maybe it has to pass a code review, too. The functional test would have to pass ensuring it does what it's supposed to do, and maybe it would need to pass a fuzz test to ensure it doesn't break under strain.

And you would need to run different contests for different categories: web apps, services, operating systems, embedded systems, phone apps, etc. Not all problems are created equal.

Re:99 bottles of beer (4, Interesting)

jbolden (176878) | about a year ago | (#45879843)

Terrific suggestion regarding Debian benchmark!

There are some pretty good stats on productivity from Cocomo II group: http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html [usc.edu] . First off you measure in terms of normalized lines of code which ends up being close to the same across languages. From there you can examine how large programs are in varieties of languages in terms of normalized lines of code and you get productivity measures:

Assembly .4
C 1
COBOL 1.5
C# 2.5
Java 2.5
Visual Basic 4.5
Perl 6
SQL 10

etc...

Perl vs. Python for relatively similar levels of experience I'd assume the differences in productivity is going to be close to 0. You seem to need rather dramatic differences on high/low level scale to get much of a productivity boost. So for example C# and Java are both 2.5; Perl and Smalltak are both 6.

Simple Answer... (2, Insightful)

Anonymous Coward | about a year ago | (#45879031)

...Some languages are good for some things, and other languages are good for other things. Think LISP.

Re:Simple Answer... (0)

i_ate_god (899684) | about a year ago | (#45879059)

What about PHP?

Re:Simple Answer... (0)

Qzukk (229616) | about a year ago | (#45879137)

PHP is unparalleled for people who want to make a webpage without having to understand HTTP.

And that's about it.

Re:Simple Answer... (5, Funny)

glavenoid (636808) | about a year ago | (#45879261)

PHP is unparalleled for people who want to make a webpage without having to understand HTTP.

Or PHP for that matter...

(...kidding...)

Re:Simple Answer... (3, Insightful)

Anonymous Coward | about a year ago | (#45879541)

Why kidding? That is one of the strongest points for PHP and VB. Those are languages that you should recommend to someone who wants to write something without learning how to program.
Sure, the result isn't something you should take to production but any programmer who deals with people who doesn't program knows that there aren't a shortage of ideas that it would be wasteful for a programmer to implement.
I think that the support to throw quickly throw together unmanageable crap is a bit under-appreciated among programmers. Sometimes a program is only meant to be ran once.

Re:Simple Answer... (3, Informative)

plover (150551) | about a year ago | (#45879755)

Srsly? Do you know how stupid executives are? "Hey, that web page that my nephew wrote, it does what we need, put it into production." A week later you get this email: "We need you to maintain it - add a loyalty registration page to this thing here, and we're getting complaints about response time..."

Re:Simple Answer... (1)

RabidReindeer (2625839) | about a year ago | (#45880013)

Srsly? Do you know how stupid executives are? "Hey, that web page that my nephew wrote, it does what we need, put it into production." A week later you get this email: "We need you to maintain it - add a loyalty registration page to this thing here, and we're getting complaints about response time..."

And someone from China just hacked it.

PHP is also good for people who want to make a webpage without understanding web security.

Re:Simple Answer... (0)

Anonymous Coward | about a year ago | (#45880113)

Give me a language with "built in" web security.

Re:Simple Answer... (0)

Anonymous Coward | about a year ago | (#45880165)

Malbolge FTW.

Re:Simple Answer... (2)

ls671 (1122017) | about a year ago | (#45879275)

Well, I do a lot of java programming and young jsp/servlet developers often know nothing about HTTP.

Re:Simple Answer... (1)

phantomfive (622387) | about a year ago | (#45879401)

PHP is unparalleled for people who want to make a webpage without having to understand HTTP.

How does knowing HTTP help you at all when making a webpage? I've written my own HTTP server, but that doesn't seem to help my web programming at all.

Re:Simple Answer... (0)

Anonymous Coward | about a year ago | (#45879655)

How does knowing HTTP help you at all when making a webpage? I've written my own HTTP server, but that doesn't seem to help my web programming at all.

Name one other programming language whose CGI interface does not require you to return the HTTP response code (eg HTTP/1.1 200 OK, half credit if you only have to call set_response(200) and it comes up with the HTTP/1.1 and OK parts itself) and set your own content headers for a proper response.

Re:Simple Answer... (2)

skids (119237) | about a year ago | (#45880089)

Perl5 CGI::. text/html and response code of 200 is the default returned by header().

There are also tricks to get PHPish code-embedded-in-static-content look and feel from Perl, but mostly people don't use that due to a general recognition that only those crazy PHP coders want to deal with that level of clutter and it's better to keep the markup inside your quoting constructs.

Anyway, futher lambasting PHP would be BTDT [veekun.com] at this point.

Re:Simple Answer... (4, Interesting)

RabidReindeer (2625839) | about a year ago | (#45880057)

PHP is unparalleled for people who want to make a webpage without having to understand HTTP.

How does knowing HTTP help you at all when making a webpage? I've written my own HTTP server, but that doesn't seem to help my web programming at all.

You would not believe how many people think that HTTP is just like old-time conversational remote applications programming. They think that once you connect to the server you stay connected and 2-way asynchronous communications are the norm. They don't understand that HTTP is a touch-and-go protocol with a strict 1-1 request/response cycle.

Re:Simple Answer... (0)

Anonymous Coward | about a year ago | (#45879345)

It's good for writing bad code.

Re:Simple Answer... (5, Funny)

K. S. Kyosuke (729550) | about a year ago | (#45879357)

Master Po: The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages. Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL, Grasshopper, if you can avoid it.

Grace Hopper: My name isn't Grasshopper, and I will program in whatever I want!

Re:Simple Answer... (0)

Anonymous Coward | about a year ago | (#45880295)

Bravo. I did not see that coming.

That's funny (2)

StripedCow (776465) | about a year ago | (#45879057)

My New Year resolution is to design and implement a new programming language every week.

Re:That's funny (1)

i kan reed (749298) | about a year ago | (#45879155)

I'm sorry, but to count as "new" you have to have something besides replacing the keyword "for" with "analsex" in ansi C.

Re:That's funny (0)

Anonymous Coward | about a year ago | (#45879361)

Ah, the 'piano teacher' approach. You just need to stay one language ahead of Mr Dawson.

Re:That's funny (0)

Anonymous Coward | about a year ago | (#45879407)

Because the piano teacher is building pianos?

Re:That's funny (0)

Anonymous Coward | about a year ago | (#45879551)

<Moe Howard>You know, for a moron you're pretty stupid.</Moe Howard>

A piano teacher only has to stay one lesson ahead of their student.

Mark TFA troll (1)

HornWumpus (783565) | about a year ago | (#45879065)

Is dice this desperate for clicks?

"...strengths of certain languages" (4, Insightful)

jdeisenberg (37914) | about a year ago | (#45879091)

And therein lies the problem of comparisons. An extreme case: a person writing a program that involves concurrency among hundreds of processes will probably be more productive in Erlang than in Perl, but a person writing a program that does massive amounts of text manipulation will be more productive in Perl than in Erlang, because of what the languages were designed for. It's somewhat like asking which is a better tool, a hammer or a screwdriver. A lot of it depends on what you're trying to build.

Re:"...strengths of certain languages" (1)

jbolden (176878) | about a year ago | (#45879179)

Moreover even between similar languages superiority can be hard to measure. Take for example the very complex and long arguments on garbage collection. Or on lazy vs. eager evaluation: where lazy can be crazy powerful but in exchange can induce algorithms / code that often become quadratic in time and memory. And then on top of all that there are the cultural issues.

Better is simply not a granular enough metric.

Re:"...strengths of certain languages" (2)

skids (119237) | about a year ago | (#45880121)

The metric should be productivity with a modifier for the language's impact on the general mental and emotional well-being of the coder.

Re:"...strengths of certain languages" (0)

Anonymous Coward | about a year ago | (#45880323)

^ This. The key isn't just, "write the same program in 99 languages." It's that every time you write anything in any language, 10 things are going on in the background that you didn't write. And depending on how you write, they may or may not happen. Completely beside the question of, "right hammer for the right job," it's that with some hammers, when you swing it, it turns out it's also turning a screw. Garbage collection is a common complaint against Java, but really, dynamic dispatch in any object-oriented language is inherently a whole other procedure that just doesn't happen in C. The two cannot be compared by any known measures.

Re:"...strengths of certain languages" (1)

jbolden (176878) | about a year ago | (#45880371)

That's exactly the point. As the level of the language goes up you start thinking into terms of highly abstracted algorithms. Low level procedures become entirely opaque even to the programmer. I can see the Assembly code when I write C. I have no idea what the engine is doing in Visual Basic.

Re:"...strengths of certain languages" (1)

Anonymous Coward | about a year ago | (#45879201)

If he writes a program that solves the same program in 56 different languages it'll give him a better understanding of this concept, he'll learn which languages are screwdrivers and which are hammers. If he writes a program geared towards the strengths of each language it will avoid this "problem". Either way he'll learn something.

Re:"...strengths of certain languages" (0)

Anonymous Coward | about a year ago | (#45879243)

Python with the numpy library does absolutely everything. It's elegance, speed, and simplicity all rolled up into an open source package. Brilliant! ... no need to learn anything else. You can even use it for web stuff.

Re:"...strengths of certain languages" (1)

phantomfive (622387) | about a year ago | (#45879365)

Python with the numpy library does absolutely everything. It's elegance, speed, and simplicity all rolled up into an open source package. Brilliant! ... no need to learn anything else.

I know people who spent their entire [programming] lives knowing Javascript and nothing else, but why? Why would you want to limit yourself that way? Suddenly it seems Python has become the hot new language.

What's next, a Python Machine? [wikipedia.org] .

Re:"...strengths of certain languages" (5, Interesting)

Anonymous Coward | about a year ago | (#45879685)

As someone who programs professionally in many languages, with about 85% of the last few years at the day job in Python (+ many years with 2 and now 3), I can attest Python has its merits, but elegance is hardly one of them. The language, standard libs, and popular third party tools are among the lower-tier of anything I've ever used.

If we forget all the other faults of python, consistency and predictability are hardly core advantages of python (no, dicts/kwargs/args aren't elegant at all). If we think about other things:

-the package management is atrocious (even with virtualenv), but more a tooling than a language issue you could say
-there still isn't what I would call great IDE support given the limitations of parsing a language like Python
-the language has changed from major versions in some pretty drastic ways, which hardly points to good design overall vs. other languages
-unicode in python 2 wasn't even the default...wtf
-the "flexibility" leads to wildly different ways of handling things
-the back and forth on things like handling lambdas and anonymous functions elegantly over the years is hardly, well, a sign of elegance
-rampant abuse of modules vs. classes
-__init__ is basically a huge wtf
-problems with circular imports

If you want something that is actually elegant, I'd suggest starting with a number of research languages. If you want something that has at least been used in major projects and proven in the field, even if not the most popular, go ahead and give Smalltalk, Lisp, and consequently Clojure a try if you seek elegance. Sorry, but I have to say Python in comparison is a toy compared to any of these languages. I'd gladly shoot the language in its face if it were legal and never wish it on my worse enemy, but hey it's a god send compared to php, perl, and many others so there's at least that.

What I tend to find is that programmers who have never used languages that can handle data structures using the core libraries and syntax of the language are easily impressed. Python list comprehensions are a good example of something that aren't that great, but "wow" if you've never seen anything that can operate on sequence or blocks before. Typically these people were C, C++, PHP, VB, or other programmers. People who worked in Lisp and/or Smalltalk are wondering how other functional, object oriented, and hybrid languages could seriously screw things up so bad when they had the benefit of hindsight.

Anology correction (0)

Anonymous Coward | about a year ago | (#45879637)

It's somewhat like asking which is a better tool, a hammer or a screwdriver.

It's more like which is better; a framing hammer or a finish hammer. Both can do the job but it would be harder driving framing nails with a finish hammer and the other way around.

More than just intent (1)

dlenmn (145080) | about a year ago | (#45879679)

Yes, some languages do things better than others, but there's more to languages than that. A good question is how well the language meets its goals.

http://xkcd.com/1306/ [xkcd.com]

Some languages are simply more clean, have a more consistent syntax, etc. then others. For example, both Fortran 77 and 90 are aimed at numerical computation, but 77 has a weird syntax made for punch cards and other oddities; 90 is just better. (Flame on!)

Re:More than just intent (0)

Anonymous Coward | about a year ago | (#45880427)

Something seems a bit off with that comic... Shouldn't $QBASIC be QBASIC$?

Not feasible (2)

Bite The Pillow (3087109) | about a year ago | (#45879871)

Repeatability. Productivity must be repeatable if any measured claims can be made, and no one does the same thing twice.

Even if you write similar code for a similar purpose, you have the backing of experience. The results are different even if you end up with the same code.

And, there are the os and third party libraries. I can save time by using such features, if I take time to learn them.

There is a post below about maintainability, securability, etc, all of which are good points, but will rarely be done exactly the same way. Especially since some are intended to be server side, where obscurity is possible, and some client side where you may need real security.

Any such study will have questionable conclusions due to the number of variables. Writing new code vs inheriting, where the choice might be maintain or rewrite in a new language.

But none of these will be applicable to an entirely new situation, and any study results irrelevant. Repeatability in code means studying something that will probably never happen again, or something so basic it will never represent normal professional usage.

Re:"...strengths of certain languages" (1)

Anonymous Coward | about a year ago | (#45880177)

Moreover, 1 week is not nearly enough time to evaluate a language. Computer languages are professional tools and, as such, should not be optimized for the first-use experience. The best computer languages optimize for the case where the user has spent the time to understand and become comfortable with the philosophy and concepts of the language. If you make such a shallow evaluation of the languages, you're likely to undervalue the languages that get better and more expressive in the hands of an expert in that language.

Better metrics (0)

Anonymous Coward | about a year ago | (#45879099)

I'd write the same program each time, and time myself doing so (including trips to wikis, documentation, and forums). Then I'd rank them by time to completion.

I'll tell you what I'm doing ... (-1)

Anonymous Coward | about a year ago | (#45879109)

I'll tell you what I'm doing for my New Year's Resolution.

Two chicks at the same time, man.

Re:I'll tell you what I'm doing ... (1)

cjjjer (530715) | about a year ago | (#45879161)

You need a million dollars, for a guy like you anyway...

Re:I'll tell you what I'm doing ... (0)

Anonymous Coward | about a year ago | (#45879249)

Lucky for me I had a great idea - the pet rock!

Re:I'll tell you what I'm doing ... (2)

larry bagina (561269) | about a year ago | (#45879887)

Look on craigs list. You can get it for $1-$2,000.

Maintainability? (4, Insightful)

cjonslashdot (904508) | about a year ago | (#45879139)

In any such trial, it is important that aspects such as maintainability, reliability and securability be considered. The ability to hack out a-lot of functionality is not the only criteria that is important, unless you are building a home hobby project.

First Step (1)

Ukab the Great (87152) | about a year ago | (#45879143)

You'll have trouble getting a consensus as to an agreed-upon operational definition of "Productivity".

Maybe the *same* program? (4, Interesting)

CompSci101 (706779) | about a year ago | (#45879145)

I have this same problem -- there are a lot of interesting languages out there that I'm interested in trying, but I always keep going back to languages I already know because:

  1. I have work to do; and
  2. it's hard to objectively compare language merits in the short term or for trivial projects.

I was thinking that the solution to this is to have one program that I understand very well implemented as well and completely as possible in a language that I feel proficient in, and have that be my reference. Then, over the course of a couple of weeks (a month?), re-implement the same program in the new language and strive for the implementation to be as idiomatic of the new language as possible. After all, if you're still thinking in the old language but just using the new one's syntax, what's the point?

I feel like this would give you a lot of data to make a reasoned decision -- you can compare language features and how the implementation works in one versus the other; time to implementation (LOC, maybe?); how much of a mental shift the new language requires; the toolchain around the new language; etc.

The problem is figuring out what the reference app is, and having the stomach for implementing it over and over again. Tetris, maybe? ;)

But, back to the resolution (and partially touched on) -- I don't think a week is enough time. A month is even cutting it close, IMO.

C

Re:Maybe the *same* program? (1)

Waffle Iron (339739) | about a year ago | (#45879913)

Whenever I try out a new language, one of the first things I do is implement the program described in the well-known paper [tc.edu.tw] by Lutz Prechelt: "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program". The program is not too big, but it gives a good feel for the features of a language and how fast it will run when you feed in a good-sized data set.

Over many years, I've done a couple of dozen implementations. However, I've found that the first impression after just learning a language may not be the best indicator. After getting very familiar with a language, I've found that I can sometimes write a much more elegant implementation than the first try.

do you relly want apps that need 2-5+ runtimes (2)

Joe_Dragon (2206452) | about a year ago | (#45879151)

do you relly want apps that need 2-5+ run times and are very bloated?

it's been tried, but not extensively (5, Informative)

Anonymous Coward | about a year ago | (#45879171)

The answer is research is sparse in this area, but the few times it's been tried (using competent programmers in each language rather than conflating learning the language and productivity in it), is LISP and LISP-like languages win [norvig.com] when measuring programmer productivity and ability to express complex algorithms in small amounts of code, and C and C++ like languages win for ultimate ability to make the program run fast. But the variability from programmer to programmer in how fast the program runs can exceed the variability between languages so it pays to get high quality programmers who have an intimate understanding of both efficient algorithms and the underlying machine architecture, rather than think "the language will make the program run fast".

Re:it's been tried, but not extensively (0)

tomhath (637240) | about a year ago | (#45879609)

LISP wins when the problem is selected based on what LISP and LISP programmers do best (list processing and recursion). Pick a different problem and LISP would be slaughtered.

Re:it's been tried, but not extensively (1)

Sique (173459) | about a year ago | (#45879953)

Luckily, about everything you could code boils down to list processing and recursion.

Re:it's been tried, but not extensively (0)

Anonymous Coward | about a year ago | (#45880375)

Recursion can make a program very, very slow and hog resources.

Re:it's been tried, but not extensively (3, Insightful)

jbolden (176878) | about a year ago | (#45880199)

As contrasted with Java? Unless you want something that is really in Java's forte (i.e. working the a Java library) I'd be hard pressed to see where LISP is likely to lose.

Now the issue of course is as the number of programmers increases LISP's idiosyncratic behaviors and allowing each developer to express their individuality go from huge advantages to huge disadvantages. At a million+ lines of code Java's maintainability and standardization become key features. But at say 20-10,000 I'm hard pressed to see much that LISP wouldn't win at.

Re:it's been tried, but not extensively (1)

jbolden (176878) | about a year ago | (#45880169)

Excellent point. Though this is mainly high level vs. low level. For example Mathematica, PHP and Visual Basic often beat LISP in terms of productivity. Norvig was commenting that LISP beats Java while managing to also be faster than Java which is what is truly impressive.

Re:it's been tried, but not extensively (1)

phantomfive (622387) | about a year ago | (#45880367)

the variability from programmer to programmer in how fast the program runs can exceed the variability between languages s

So true

Languages for professionals (5, Insightful)

gnasher719 (869701) | about a year ago | (#45879191)

With everything, there are professional users and amateur users. For amateur users, it's important to get reasonably good results with relatively low effort without much learning. For professionals, what counts is the effort for projects the size a professional does, after learning a lot.

Trying a new programming language every week cannot give any useful information to a professional user, because the language can only be judged on how well it works for inexperienced developers on tiny projects. That's not what professionals do.

Re:Languages for professionals (1)

dbc (135354) | about a year ago | (#45879627)

I'll agree, and add that it takes a certain amount of time to get into the 'Zen' of any particular language. I've been programming since the 1970's, and lost track of the number of languages I have used. When I learned Python, I was productive immediately -- but my code looked more like C or C++. It took me a while to learn to think in 'Pythonic' code, with list comprehensions, generators, etc. Same for Prolog -- Prolog does not become natural in a week.

I'm doubtful that a week spent on any one language can give anyone the sense of it's underpinnings. As a friend once said: "A good programmer can write FORTRAN in any language."

Re:Languages for professionals (1)

Sique (173459) | about a year ago | (#45879995)

But on the other hand, having seen so many programming languages and how they handle things will give you the ability to assess each new language very fast and understand their intrinsic details because you have seen the same thing several times already.

It's the same with foreign languages: You understand your own language much better if you have mastered at least on foreign one.

Re:Languages for professionals (1)

slickrockpete (868056) | about a year ago | (#45880025)

Yes Deep understanding comes from deep and interesting use. A professional is forced into deep understanding. A hobbyist, dabbler, autodidact or amateur is unlikely to go deep, but some do. A week is not really enough time to go deep.
All that said this sounds like it will be a good learning experience if he can pull it off. The first thing is just getting over syntax. Just translating between all the procedural languages will get you somewhere, but will get severely boring. A lot of people stumble over syntax.
The more interesting thing is noticing the underlying fundamentals for each language. I hope he can use some of the interesting ideas behind each language even though most will allow you to just translate the syntax using the procedural subset. The fact that he used haskell first bodes well.

Programming Language Warning (1, Funny)

MonkeyDancer (797523) | about a year ago | (#45879207)

If your using a programming language, but your language is not enough, then you should consult your doctor.
Call your doctor if your application worsens, or if you have unusual changes in mood, behavior, or thoughts of suicide.
See a doctor if you have high fever, stiff muscles, confusion, or having trouble swallowing.
Some adverse affects are: diarrhea, seizures, and flatulence.

sort of (1)

phantomfive (622387) | about a year ago | (#45879209)

Simon Peyton Jones points out that doing 'clinical trials' for programming languages is hard, because it's expensive, and because "programming language is weak on that score.....culturally we're not well adapted to it."

He also points out that Microsoft does something similar, they do usability testing for their APIs and languages, where a researcher sits behind a glass window, and watches programmers try to figure things out.

For pure efficiency, the benchmark game [debian.org] at least gives some data points. From a gut feeling, I would say LISP is rather good at letting you do the most in the least number of lines (dependency injection is insanely easy, for example, compared to Java where it's painful if you haven't planned for it).

Re:sort of (0)

Anonymous Coward | about a year ago | (#45879385)

Java dependency injection... is that good for a quick hit when you run out of coffee? I don't like needles, so I'd rather have some of this [youtube.com]

There is no language superiority (2)

Aviancer (645528) | about a year ago | (#45879233)

This is a myth. There is only suitability to solve a problem within a given context. At first, it's "how fast can I bring this to market", then "how does this scale" (in terms of execution efficiency). Finally, "can I hire people to do this?"

The starting point is inevitably what the initial implementer is most familiar with (or infatuated with) at the moment.

A few weeks ago, I wrote an article about how asinine this technology argument is [paulwilliams.biz] .

Re:There is no language superiority (-1)

Anonymous Coward | about a year ago | (#45879493)

There is no language superiority

Spoken like someone who hasn't spent years mastering Haskel. You can get a jump on everyone else by writing a human-readable Haskel interpreter in Perl. See you next decade.

Re:There is no language superiority (1)

jbolden (176878) | about a year ago | (#45880307)

I've agreed with that for years. Haskell is like using a programming language out of 2025 today.

Re:There is no language superiority (0)

Anonymous Coward | about a year ago | (#45880011)

This is a myth.

Exhibit A. [wikipedia.org]

Programming language design is not a zero-sum game. It is very much possible for a language to be objectively superior or inferior to another language.

actual clinical trials are nearly impossible (3, Funny)

Trepidity (597) | about a year ago | (#45879305)

Some key features of "gold standard" clinical trials: 1) large enough sample size to draw statistically significant conclusions; 2) real illnesses, not a simulated laboratory setting; 3) a double-blind control group; and 4) long enough duration to measure real-world outcomes.

The programming-languages version would be to have teams randomly assigned to perform major (6+ month) programming projects in different languages, and then see their outcomes. For example, 40 game studios will continue to write their games in C++ as the control group, while you'll have the other 40 write them in Haskell. You probably want to iterate a few times as well to make sure that there's no first-game-in-a-new-language effect and to ensure that everyone is actually knowledgeable in the language being tested.

Oh, and it should be blind, so neither the teams nor the researchers know which language they're using.

Enthusiasm, Free Time and Resources (1)

Sponge Bath (413667) | about a year ago | (#45879423)

Enjoy it while you can. Soon enough, job and family concerns will consume most of your attention.

Dr. Lizardo said it best: "Laugh'a while you can, monkey boy!"

Double Blind? (0)

Anonymous Coward | about a year ago | (#45879457)

Don't laugh. Ever seen C that looks like the programmer thought that they were using Fortran?

Re:Double Blind? (0)

Anonymous Coward | about a year ago | (#45879779)

Ever seen C that looks like the programmer thought that they were using Fortran?

Well, you can't spell 'Fortran' without 'C'. Oh, wait, that's 'COBOL'. Damn it. Give me 5 minutes and a swiss army knife and I'll figure this out.

aren't i so damn trendy? (4, Insightful)

Connie_Lingus (317691) | about a year ago | (#45879535)

it's my observation that programming languages have become the equivalent of fashion and bands.

it's as if choosing and using one is like saying "oh, im listening to arctic monkeys and calvis harris these days, and that makes me feel liberated from those plebs still listening to kings of leon and david guetta..and MAYBE if im lucky someone will be impressed by my trendiness"...now that so many 20-somethings code, they all seem to feel the need to break from the "boring old bonds" of existing languages and define themselves among their peers by how esoteric their language-de-jour is.

what this guy is doing is illustrating the point, he isn't going to learn anything about the benefits of each "language" or how to maximize productivity...it's just a "notice me notice me" stunt.

it's just a silly exercise in syntax-swapping anyway for 90% of it...

please don't get me wrong...it's totally fine by me whatever language you want to use, as long as it's maintainable and there is a large enough pool of existing programmers who know the language so when you leave my company because your bored with maintaining the code you wrote, i can find someone quickly and affordably to replace you.

Re:C/C++ Bugs (0)

Anonymous Coward | about a year ago | (#45880413)

We are sick of software bugs, the new guys write better software!

Clinical Trials (0)

Anonymous Coward | about a year ago | (#45879647)

To Mr. Charles Dawson, good luck writing a program in assembly. I am still trying to grasp the complex language.

Use the Best Tool for the Job (0)

Anonymous Coward | about a year ago | (#45879751)

As they say, use the best tool for the job. Put away your e-peen.

For example:

1. If you need concurrency, look at languages like Clojure and Erlang among many others that make it easy. Further break down what sort of concurrency requirements you really need.

2. If you need speed, look at something like ASM, C, etc.

3. If you need to work a lot with standard data structure but in complex ways, Lisp, Clojure, many others...

4. If you need a web framework in a box rather than exerting effort to build something that matches your need, find one you like and just use it knowing its limitations.

In the real world when people write software that is often not just 1 application, embedded, or a stupid blog, we use multiple languages and systems to get the job done right. Why would I write my web page in C++ if it takes me 10x longer. Conversely, why would I write a raytracer in PHP or some language more suited to RAD?

Be a computer scientist, not a Ruby Programmer. If you can compromise to keep things in a few or even one language, great, but do so knowing the costs, not just because you are someone who only knows how to program well in JavaScript. If you can't program well in more than one language, you really need to find a new career, sorry.

Wrong Metaphor (1)

ndykman (659315) | about a year ago | (#45879941)

One of the hallmarks of a clinical trail is that a random group of humans will respond about the same to a given intervention (or lack thereof). And for things like drugs or a medical treatment it's an assumption you want to hold up for safety's sake. It doesn't always, of course. There is a drug on the market that is targeted specifically for African Americans, as it works really well in that population.

However, that assumption just don't hold for a random group of developers. Not even close.

Concentrate instead on types of applications (0)

Anonymous Coward | about a year ago | (#45879971)

The act of using many different syntax languages will not gain you all that much, although the confidence factor may be worth something to you personally. Instead, why not tackle different kinds of applications, such as database, computational, graphics, embedded, operating system, expert system, and so on. Choose a C-syntax language that's popular for each. Each will have their interesting syntax variations, with the differences will made more apparent by the application.

Live and don't learn (1)

DavidHumus (725117) | about a year ago | (#45880035)

After decades of enjoying the extreme and obvious productivity advantages of programming with dynamic languages in interactive environments, I continue to be baffled by the overwhelming preference for static, compiled languages. I understand there is a place for such things, much as there is a place for programming in assembly language, but I continue to wonder why such a clumsy paradigm is so dominant.

Re:Live and don't learn (3, Insightful)

jbolden (176878) | about a year ago | (#45880333)

Because the productivity doesn't scale well as projects get larger. Dynamic languages are amazing at 20 line programs. They are pretty hot at 200 lines programs. At 2000 lines you are starting to feel the minus but they still work well. At 20,000 things start going badly wrong. By 2m, well there are 2m line programs mostly because all those things that are good about a dynamic language for 20 lines turn into disadvantages when you need hundreds of programmers to work together.

all this means... (0)

Anonymous Coward | about a year ago | (#45880053)

...is that he'll suck in all the languages because he isn't focusing on anything in particular.

New religion & flame war coming. (1)

vikingpower (768921) | about a year ago | (#45880081)

Soon to be featured by a /. outlet in your galaxy , yay !!

Different languages, different issues. (4, Interesting)

fahrbot-bot (874524) | about a year ago | (#45880115)

There are good practical reasons for writing the same program in different languages. (1) People often make the same mistakes in the same language, because they are often taught/trained in similar fashions. (2) Different programming languages have different issues and failure modes.

I'm not an expert, but I worked as an undergraduate research assistant on a project way (way) back in college (1985-87) for a professor on a NASA contract to study issues related to N-version fault tolerance - like used on the Shuttle, where several computers solve the same problems and vote on the answers. One problem (if I remember correctly) was that the different programs, written by different people, in the same, or same type of, language often failed on the same or similar edge cases.

The experiment was to implement the same solution to a problem using much different languages. In this case, Pascal and Prolog. The "gold" Pascal routine was already written and my task was to write the corresponding "gold" routine in Prolog. [ I also did work for a related study in the automatic analysis (and execution) of abstract data types in LISP.] I graduated before the experiment was run, but found the idea as least plausible.

Note that I might be remembering some of this incorrectly as it was a while ago and I was only an undergrad. (They wanted a graduate student, but I was the only one with LISP and Prolog experience... And $9.50/hour wasn't bad for 1985.)

Rosetta Code (1)

Anonymous Coward | about a year ago | (#45880167)

I'm surprised to see that no one has mentioned Rosetta Code [rosettacode.org] yet. It provides many examples of different (real-world) problems being solved in many different languages. It's interesting for comparisons between languages and it's very useful for finding already-implemented solutions to problems in whatever language a user may require.

Wrong resolution (0)

Anonymous Coward | about a year ago | (#45880263)

The poster's a High School junior? Wrong resolution. Get in shape, if you're not already, and then chase tail. You won't be young forever. You have decades ahead of you to sit in front of screen doing stuff.

A good lesson (5, Interesting)

jgotts (2785) | about a year ago | (#45880389)

It's a good lesson, but for different reasons. Here's why.

In the real world, you pick the right tool for the job. You never pick a language because it's the best language. There is no such thing. Factors going into language selection where technical merit plays no role include what the other developers at the company and/or the project are using, what environment you're using (if Apple, then Objective C; if Android, then Java), what language the code you are maintaining was written in 5, 10, 20, or 30 years ago, and (hopefully if you are a great programmer this will be a minor issue) what languages you're comfortable with using.

After 30 years I've learned that basic computer science concepts are helpful, but only to a point. Google may want you to know specifics about certain types of trees for their interview process, but if you need to know that level of detail for a job, you spend a few hours on Google and learn it. The same goes for languages. Figure out what you need with a bit of research before you start the job. You should have a great idea of what environments a language is nearly always used, so you don't try to do something weird nobody can maintain. If you're going to write an iPhone app, you're going to adhere to whatever specific Objective C thing Apple is doing. Maybe I'm slightly out of date and Apple is doing something else, who knows? I don't work in that space.

Python everywhere, be damned with you, is a quick way to make enemies of people 10-20 years down the road who have to maintain your code. I was doing web development in the 1990s, and everybody used Perl. For everything. Now I work with a legacy Perl code base, and mod_perl seems to be completely abandoned, and it certainly hasn't been released for apache httpd 2.4 yet. We're using Perl because we have to, but not for new stuff. But for the Perl part of our system in bug fix maintenance mode, it is the appropriate language. We didn't have the attitude that we'd continue to use Perl for everything just because that's the way things were done. We were flexible enough to slowly switch over to PHP for certain things that we had been using Perl for.

Avoid fads like the plague. After 30 years of programming, I just ignore marketing. I have no gee whiz attitude about anything. I focus on perfecting my craft, learning how to program better, to debug better, to test better. Learning how to deliver code that works now and five years from now. All that is way more important than figuring how how some language is subjectively the best.

C++ (0)

Anonymous Coward | about a year ago | (#45880423)

I have been programming in C++ for 10 years and realize that there is much more in C++ to be learned, how big it is and how smart the person was that implemented that feature. One thing that always strikes me is code that I write 2 years ago and review later on. A lot of times, I have to fight the urge to rewrite something in a better, more extensible and consistent fashion. It is funny how your perception of a problem changes over time and experience. Even things like collections and strings are just huge and depend on libraries which influence your design. Just looking at the differences between C++ 2.0 and 3.0 opens up a world of implementation subtleties that take time to resolve and clean up.

Now, if you experience this with a language that you know, then yes, you can try to implement the same algorithm in Java and C#, but you will be influenced by the experience. Afterwards, your C++ will begin to look like C# and Java.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?