Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming

"Clinical Trials" For Programming Languages? 232

Posted by samzenpus from the apples-and-oranges dept.
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?"
This discussion has been archived. No new comments can be posted.

"Clinical Trials" For Programming Languages? More

"Clinical Trials" For Programming Languages?

Comments Filter:

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

    by Anonymous Coward on Monday January 06, 2014 @11:50AM (#45878931)

    long flamewar

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

      by Anonymous Coward on Monday January 06, 2014 @12:20PM (#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 ... (Score:5, Insightful)

      by DuckDodgers ( 541817 ) <keeper_of_the_wolf @ y a h oo.com> on Monday January 06, 2014 @12:23PM (#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 ... (Score:5, Insightful)

        by brausch ( 51013 ) on Monday January 06, 2014 @01:36PM (#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: (Score:3)

          by jythie ( 914043 )
          Making it even worse, different languages are not only designed to solve different technical problems, but they are designed to solve different HR problems. How easily one can get developers who are both familiar with the domain AND the language, or know a language so close that transitioning is easy (i.e. why most languages looks like C) is just as critical as in how well a language fits a project as the technical aspects.

          Which is why language wars can get so flamey.. each one is heavily tangled up in cu

          • Making it even worse, different languages are not only designed to solve different technical problems, but they are designed to solve different HR problems.

            I agree. That does make them worse. C++ wouldn't be where it is today if it didn't incorporate C -- This is both a good and a horrible thing to realize if you look at the state of things.

            However, the "different language for different people" problem is one created by humans. You see, C is the way it is because it tries to minimally abstract the operations common to Von Neumann machine architecture. Nearly all modern languages fail in two respects: They are either too abstract and dynamic or too concret

      • I did something similar when learning some new languages, or getting back up to speed in languages I had only learned from a book. I'd write essentially the same program over again in the new language. It was helpful, however I think it had some drawbacks. You tend to want to re-create the same style you already have in the new language, rather than adapting to the new language's style. So I had to force myself to try and think like the new language wants.

        Ie, you can port your basic procedural program t

        • I learned Pascal and Modula-2 and C and then started using Perl in the web LAMP stack. When I wrote my first Java program, it was straight up procedural. Even I could tell that. Some of my coworkers said it was objects because we used Java. Syntax ain't the same as architectural orientation.

          The hardest thing to do for an accurate comparison is deciding on the measurements. Is it speed of processing, speed of programming, ease of maintenance? There are lots of different real-life problems that need to be

    • Re:That is a beautiful start of a ... (Score:5, Funny)

      by alex67500 ( 1609333 ) on Monday January 06, 2014 @12:39PM (#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

  • 99 bottles of beer (Score:5, Informative)

    by jbolden ( 176878 ) on Monday January 06, 2014 @11:55AM (#45879003) Homepage

    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]

    • Re:99 bottles of beer (Score:5, Insightful)

      by Savage-Rabbit ( 308260 ) on Monday January 06, 2014 @12:36PM (#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 (Score:5, Insightful)

        by plover ( 150551 ) on Monday January 06, 2014 @12:56PM (#45879721) Homepage Journal

        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 (Score:5, Interesting)

        by jbolden ( 176878 ) on Monday January 06, 2014 @01:08PM (#45879843) Homepage

        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.

      • The Debian Benchmarks game often over-specifies the problem by requiring a particular approach.

  • Simple Answer... (Score:2, Insightful)

    by Anonymous Coward

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

  • That's funny (Score:3)

    by StripedCow ( 776465 ) on Monday January 06, 2014 @11:59AM (#45879057)

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

  • Is dice this desperate for clicks?

  • "...strengths of certain languages" (Score:5, Insightful)

    by jdeisenberg ( 37914 ) on Monday January 06, 2014 @12:02PM (#45879091) Homepage
    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: (Score:2)

      by jbolden ( 176878 )

      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: (Score:3)

        by skids ( 119237 )

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

    • 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!)

    • 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 ex

  • Maintainability? (Score:5, Insightful)

    by cjonslashdot ( 904508 ) on Monday January 06, 2014 @12:06PM (#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.

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

  • Maybe the *same* program? (Score:5, Interesting)

    by CompSci101 ( 706779 ) on Monday January 06, 2014 @12:06PM (#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

    • 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 afte

  • do you relly want apps that need 2-5+ runtimes (Score:3)

    by Joe_Dragon ( 2206452 ) on Monday January 06, 2014 @12:07PM (#45879151)

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

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

    by Anonymous Coward on Monday January 06, 2014 @12:09PM (#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: (Score:2)

      by jbolden ( 176878 )

      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.

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

      So true

  • Languages for professionals (Score:5, Insightful)

    by gnasher719 ( 869701 ) on Monday January 06, 2014 @12:11PM (#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: (Score:2)

      by dbc ( 135354 )

      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 langu

      • Re: (Score:2)

        by Sique ( 173459 )
        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.

  • 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

  • There is no language superiority (Score:3)

    by Aviancer ( 645528 ) on Monday January 06, 2014 @12:13PM (#45879233) Homepage Journal

    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].

    • Yes, there most certainly is such a thing as language superiority. It can even be somewhat measured.

      For example, if, to solve a problem, language A takes about 30 lines of extremely clear code that takes the programmer about an hour to do, that's obviously superior to language B that takes 1000 lines of gobbledygook that takes the better part of a week. Especially if, when both programmers get a change request to their little application, language A is modified and the update ready in 10 minutes while langu

    • I welcome you to see the merit of Brainfuck [wikipedia.org], Befunge [wikipedia.org], or any of a plethora of other programming languages that are objectively not suitable to solve any type of problem better than, say, C or Java. So your basic premise is false. It might be that Scala and Lisp both have their objective sweet spots, but it might equally well be that one is better than the other -- if tested correctly.

      And BTW, this post was a valid Whitespace [wikipedia.org] program until your renderer ate my tabs.

  • 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.

  • 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!"

  • aren't i so damn trendy? (Score:5, Insightful)

    by Connie_Lingus ( 317691 ) on Monday January 06, 2014 @12:37PM (#45879535) Homepage

    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: (Score:2)

      by skids ( 119237 )

      Being one who has strong preferences about languages and routinely wears white socks with sandals, which has seldom ever been trendy, I have to say you are reading less into the gripes about programming languages than is there. Reality sets in the 200th or so time you type out InsanelyAribtraryFUNCTIONName(Nonsensically:formatted.thing_with_obscure_british_spelling_of_colour) and realize that there really is no solid underpinning to the particular language and people pretty much make up APIs and interfaces

  • 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.

  • 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 (Score:4, Insightful)

      by jbolden ( 176878 ) on Monday January 06, 2014 @01:54PM (#45880333) Homepage

      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.

      • I have personally worked on a couple of different 20,000 line code bases in dynamic languages.

        They worked just fine: in one case we had about 20 clients buying in for tens of thousands per system + 20 % maintenance, which required one senior and one junior programmer to maintain; the other was a system with about three programmers that accounted for about 1% of the trading volume on the NYSE.

        You do not have systems in the millions of lines with dynamic languages because you do not need that many lines to do

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

  • Different languages, different issues. (Score:5, Interesting)

    by fahrbot-bot ( 874524 ) on Monday January 06, 2014 @01:30PM (#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.)

    • Might be a bit off-topic, but when the system gets (for example) 5 answers from 5 different computers, how do they make sure that the program/computer that reads and verifies those 5 answers is correct and fault tolerant?

      • Might be a bit off-topic, but when the system gets (for example) 5 answers from 5 different computers, how do they make sure that the program/computer that reads and verifies those 5 answers is correct and fault tolerant?

        Don't know and don't know if that situation ever occurred. Any Shuttle computer systems experts out there?

        In any case, here's a link to a paper titled, Redundancy Management Technique for Space Shuttle Computers [psu.edu]

  • A good lesson (Score:5, Interesting)

    by jgotts ( 2785 ) <jgotts@@@gmail...com> on Monday January 06, 2014 @01:59PM (#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.

    • Re: (Score:2)

      by jbolden ( 176878 )

      I'm not sure I would generalize too much from Perl. Perl had a terrific run going from a text processing language to a system admin language to the standard for web development. Then it moved towards applications development. And then it faltered badly. They responded to the faltering with an overly ambitious and poorly managed next version which has sucked the life out of the language.

      Perl is an example of picking a technology that died. Lots of people who have picked lots of technologies they thought

      • They responded to the faltering with an overly ambitious and poorly managed next version which has sucked the life out of the language.

        Python is in the middle of a 'next-version' crisis, too.

    • In a perfect world, you pick the right tool for a job. In the real world: your customer or your boss choses the (right, not so right) tool for the job.
      Half of /. are Java haters, nevertheless many of those work with Java. The other half are C# haters but nevertheless work with .Net/C#
      The rest are Python and Perl lovers, but work with C/C++
      AFAICT: there is no real world. There are only plenty of dream worlds. It is up to you if your dream world is occupied/ruled by a nightmare.

    • ...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....

      These types of questions are finding out your breadth and depth of knowledge about data structures and algorithms. No, you cannot become proficient in this area in a few hours. You need reasonable proficiency to even be able to intelligently Google the appropriate specific knowledge. I find that knowledge of data structures and algorithms is essential for being a competent programmer.

  • What I'm trying to do (Score:5, Informative)

    by cdawson ( 3487957 ) on Monday January 06, 2014 @02:26PM (#45880659)
    Hi everyone. Thanks for all of your comments. I just want to quickly elaborate on why I'm doing this and what I'm trying to do with this project: I am not trying to start a flamewar, annoy programmers, or hog attention. I am not aiming to master any of these languages after only a week. I'm not even trying to get "okay" at any of them. All I'm trying to get out of this project is a more broad understanding of the languages that are out there, and what, in a very general sense, each language is good for. My thought is that if I can get even one cool new idea or concept out of each week's programming language (like functional programming concepts from this week's foray into Haskell), I'll consider this project a success. Also, it will allow me in future to be able to quickly reference a new language if I need it for something I'm working on (not necessarily remember any syntax or anything, but at least to save myself some googling time). Thanks for your interest. Sincerely, Charles Dawson

    • If understand correctly: 52 projects in 52 languages in 52 weeks? A high school junior? You're nuts for even trying this.

      I like that. :) Good luck, have fun, and I hope you learn a lot. We each have our ways of learning programming and this seems like an interesting way to do it.

      • Using a week to learn a language and do a small project on it isn't that crazy. The problem is just that after week 30 or so, you start to run out of sane and useful languages (unless you dig into the obscure) and end up experimenting with brainf**k.

    • Yepp, welcome!
      However you could have googled for your questions rather than asking here and claiming in your question that there never has been any study.
      The world is full with studies about various languages or concepts since ... hm roughly 1965 (yes, 1965, not only 1985)

  • We all know innately know this, but sometimes it's hard to avoid getting caught up in a religious debate about the apples-to-oranges details.

    Once your language is at least complex enough to write a compiler or interpreter for itself - that is, it's no longer a toy language - it tends to be more or less capable of everything every other language is capable of. Sure, it might not be the best tool for a given job, but they're all generally the same aside from some syntactic sugar.

    The more important thing is t

    • Thank you. It's like asking what language should diplomats use to negotiate a peace. Obviously, the most productive language is the one in which people are extremely competent and comfortable using...until they need to describe the the 27 types of snow, in which case they can switch from a European language to an Eskimo language to better express the concept. I assert a language's strengths and weaknesses for an idealized problem are trivial...compared to the strengths and weaknesses of the individuals

Slashdot Top Deals

Man is an animal that makes bargains: no other animal does this-- no dog exchanges bones with another. -- Adam Smith

Close