Is the Right Tool a Matter of Preference?

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Is the Right Tool a Matter of Preference?

Postby sourmìlk » Thu Jun 28, 2012 8:42 pm UTC

I'm writing a game engine, and I'm using C++ and I'm liking it very much, largely because of all the crazy shit it allows me to do (like initializing a custom Vector class that's sized based on a template argument with variadic functions that are checked on compile time to have the right number of arguments).

But then I see all these articles about how some other language (usually a functional one) is the best for all tasks because it reduces development time, and if you use it right the performance is fine, etc. And that makes me worry, because I don't want to think that I've been spending tons of time on a project using an inferior tool.

My dad (a computer scientist) says that this is all religion though: people treat their preferences as objectively correct, when they're just preferences. So my question is: is this the case? Are there objectively better language and paradigms for every task (or for any task)? Is it a matter of preference? If I'm writing code that works efficiently and I'm enjoying using the language, is that a sufficient basis upon which to use the language?
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Fri Jun 29, 2012 12:16 am UTC

For the most part enjoying the process is sufficient reason to keep doing it that way.

On the other hand, you most certainly should learn to use all the tools you can. In particular, I would recommend learning functional programming before too long. You can take a lot of the lessons back to C++.

Suppose all possible languages exist. Then for any given problem X there is a language that minimizes code length / development time / maintenance costs / etc. Call this language Y, which is objectively the right tool for the job. Now, since not all languages exist, you'd ideally like to specify Y and then program in that language. Now, what languages do we know that are optimal for the task of specifying other languages?

User avatar
OmenPigeon
Peddler of Gossamer Lies
Posts: 673
Joined: Mon Sep 25, 2006 6:08 am UTC
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby OmenPigeon » Fri Jun 29, 2012 1:21 am UTC

Ben-oni wrote:Suppose all possible languages exist. Then for any given problem X there is a language that minimizes code length / development time / maintenance costs / etc. Call this language Y, which is objectively the right tool for the job.

You can only assume that Y is unique if you ignore the fact that programs are written by particular humans at a particular time. The language that minimizes my code length, development time and maintenance cost on a problem is almost certainly not the same as sourmilk's, or me-five-years-ago, or me-five-years-from-now. One of my ex-coworkers was an enormous fan of direct memory management, pointer arithmetic, weird struck packing tricks, funky bitwise micro-hacks and all that. His best language for almost any project would be something in the neighborhood of C++, if only because he enjoyed using it so much. I hate all of those things, so I would do terrible work on his C++ codebase.

It's certainly worth exposing yourself to many different things that other people think are the One True Way, but that doesn't mean that they actually One and True. The only code that matters is code that ships, so if you hate all of Ruby's spooky-action-at-a-distance nonsense Rails probably isn't the right tool, no matter how productive all those other Rails programmers are.
As long as I am alive and well I will continue to feel strongly about prose style, to love the surface of the earth, and to take pleasure in scraps of useless information.
~ George Orwell

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Fri Jun 29, 2012 7:53 am UTC

OmenPigeon wrote:You can only assume that Y is unique if you ignore the fact that programs are written by particular humans at a particular time. The language that minimizes my code length, development time and maintenance cost on a problem is almost certainly not the same as sourmilk's, or me-five-years-ago, or me-five-years-from-now. One of my ex-coworkers was an enormous fan of direct memory management, pointer arithmetic, weird struck packing tricks, funky bitwise micro-hacks and all that. His best language for almost any project would be something in the neighborhood of C++, if only because he enjoyed using it so much. I hate all of those things, so I would do terrible work on his C++ codebase.

You managed to completely miss the point.

1) Suppose we only care about one aspect: code length. The a language that minimizes code length is one that compiles an empty source file into your program by default. Granted, it's not very useful since any change in program requirements will involve massive changes to the program code. So also consider maintainability. Now an optimal language needs to have the property that similar requirements are satisfied by similar source codes. This is all very objective and doesn't enter the realm of subjectivity until development time. Now we want a language in which it's easy to reason about the problem domain. None of this implies that the optimal language is the one known by a particular programmer. When all you have is a hammer doesn't apply.

2) Uniqueness is not a requirement of the thought exercise. We don't even need to consider a global optimum: considering a locally optimal language is sufficient for this exercise.

3) All the tricks you think you know are irrelevant. This exercise isn't about what language has all the features you love. It's not about language features at all.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby korona » Fri Jun 29, 2012 6:11 pm UTC

I don't think a functional programming language would be the right tool to develop a game engine.
Pure functional languages are based on the concept that there is no state (no function must have side-effects that are visible outside the function). In a game you usually have to manage a lot of state.
Functional languages developed tools to model state in a function environment but non-functional languages usually have much better syntactic tools to deal with state.
With C++11 lambdas and templates you can easily use functional style in C++ when that is appropriate (e.g. when your function don't have side-effects).

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Fri Jun 29, 2012 7:20 pm UTC

korona wrote:I don't think a functional programming language would be the right tool to develop a game engine.
Pure functional languages are based on the concept that there is no state (no function must have side-effects that are visible outside the function). In a game you usually have to manage a lot of state.

That's a rather simplistic way of putting it. Overly so, in my opinion. State is one way of modeling what a game does. While the basis of FP is stateless functions, the theory moves far beyond that, and is useful in game programming. See Functional Reactive Programming for an example of abstraction beyond state.

korona wrote:Functional languages developed tools to model state in a function environment but non-functional languages usually have much better syntactic tools to deal with state.

Oh really? If by "better" you mean "more error-prone", then yes. Otherwise, that's very doubtful.

korona wrote:With C++11 lambdas and templates you can easily use functional style in C++ when that is appropriate (e.g. when your function don't have side-effects).

You can do some functional programming. The scope of what's possible extends beyond my comprehension of the language, so I won't pretend to say where the limits are, but learning FP techniques in a language new to them sounds like a disastrously bad idea.

User avatar
OmenPigeon
Peddler of Gossamer Lies
Posts: 673
Joined: Mon Sep 25, 2006 6:08 am UTC
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby OmenPigeon » Sat Jun 30, 2012 2:44 am UTC

Ben-oni wrote:1) Suppose we only care about one aspect: code length. The a language that minimizes code length is one that compiles an empty source file into your program by default. Granted, it's not very useful since any change in program requirements will involve massive changes to the program code.

Sure. If you ignore all other factors, then there should be some language, even some non-absurd one, that minimizes the length of a particular program.

Ben-oni wrote:So also consider maintainability. Now an optimal language needs to have the property that similar requirements are satisfied by similar source codes. This is all very objective and doesn't enter the realm of subjectivity until development time. Now we want a language in which it's easy to reason about the problem domain. None of this implies that the optimal language is the one known by a particular programmer. When all you have is a hammer doesn't apply.

This isn't right. Reasoning (about problem domains or other things) is done by people. They use languages, but the language can't do the work for them. (No, not even Haskell's type system.) And languages aren't just a bag of tricks, they're patterns of thought. Based on your expressed fondness for functional code, I suspect you'll agree with me that `map` is generally simpler and more maintainable than `for(...)`, right? I've worked with programmers, really good ones, who vehemently disagreed. It's not that they didn't understand higher-order functions and lambdas and whatnot, they just literally thought in terms of loops, not functions. They're going to be able to more easily maintain a program written like that, in a language that encourages it, and you'll do the opposite. "Similar requirements are satisfied by similar source codes" is good, but it's not the be-all, end-all of software maintenance.

Ben-oni wrote:3) All the tricks you think you know are irrelevant. This exercise isn't about what language has all the features you love. It's not about language features at all.

You seem to think it's about creating Gods own abstraction to solve every problem. I think it's about shipping. Unsurprisingly, those are leading us down rather different paths.
As long as I am alive and well I will continue to feel strongly about prose style, to love the surface of the earth, and to take pleasure in scraps of useless information.

~ George Orwell

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Sat Jun 30, 2012 6:46 pm UTC

I'm going to clarify something:

I certainly don't mean to imply that there are tools one shouldn't even learn how to use. Even if functional programming is the stupidest choice ever for my purposes, I certainly agree that it's worth learning. (I've been taking a look at it, and it's cool, but all the recursion is making me a bit uncomfortable. I empathize with the stack.) The question is whether there is a best tool for a job, whether I can determine what that tool is, and whether that tool is always the best tool for the job regardless of who is using it.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Sat Jun 30, 2012 7:58 pm UTC

sourmìlk wrote:I'm going to clarify something:

I certainly don't mean to imply that there are tools one shouldn't even learn how to use. Even if functional programming is the stupidest choice ever for my purposes, I certainly agree that it's worth learning. (I've been taking a look at it, and it's cool, but all the recursion is making me a bit uncomfortable. I empathize with the stack.) The question is whether there is a best tool for a job, whether I can determine what that tool is, and whether that tool is always the best tool for the job regardless of who is using it.

Every tool can be misused. That doesn't mean it isn't the best tool. If you have a screw, a screwdriver is the best tool (though it might not be obvious if you should be using a manual or power screwdriver). Give somebody a nailgun and, yes, they can nail their feet to the floor, but that doesn't stop it from being the right tool.

When you need to do a bunch of graphics rendering, OpenGL might be the right tool (even if you don't know how to use it); for xml searching, xpath. Large sets of homogeneous data? Use relational databases and SQL. All of these have something in common: they are languages optimized to a particular problem domain, and they don't overlap. Furthermore, they can be used directly within a host language. (OpenGL is implemented as a series of datatypes and functions with call-order semantics; xpath and sql are generally passed in strings to driver-code.)

Anyways, my thought exercise was about how easy (or hard) it is to implement domain specific languages into your program. It doesn't matter if someone prefers "for" over "fold". When your toolbox lacks the specific tool you need (perhaps it hasn't been invented?), can you create that tool?

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Is the Right Tool a Matter of Preference?

Postby Sc4Freak » Sun Jul 01, 2012 12:27 am UTC

Ben-oni wrote:
sourmìlk wrote:I'm going to clarify something:

I certainly don't mean to imply that there are tools one shouldn't even learn how to use. Even if functional programming is the stupidest choice ever for my purposes, I certainly agree that it's worth learning. (I've been taking a look at it, and it's cool, but all the recursion is making me a bit uncomfortable. I empathize with the stack.) The question is whether there is a best tool for a job, whether I can determine what that tool is, and whether that tool is always the best tool for the job regardless of who is using it.

Every tool can be misused. That doesn't mean it isn't the best tool. If you have a screw, a screwdriver is the best tool (though it might not be obvious if you should be using a manual or power screwdriver). Give somebody a nailgun and, yes, they can nail their feet to the floor, but that doesn't stop it from being the right tool.

Fundamentally, I think that's where a lot of the disagreement in this thread is coming from.

A tool is simply something that helps you do something faster, safer, more efficiently, or whatever it is that your goals dictate. If you're writing an iPhone game for a client, your goal (presumably) is to complete your deliverables as quickly and efficiently as possible, while meeting your client's requirements and quality bar. And so, your choices in tools should obviously reflect that. Regardless of any theoretical arguments about the suitability of tools, it's unlikely that (say) Haskell or Lisp would be suitable tools for the specific job of iPhone game development especially if you're not familiar with them. Why? Because they don't help you achieve your goals! I think it's quite simple, really.

If the Amish are building a house, what would you give them? A hammer and nails, or an electric nailgun? For someone who's never seen such a device, they may very well be liable to nail their feet to the floor and cause a lot of injury and consternation. Does that still make it the "right" tool when a simple hammer and nails would work better in helping them complete their goal of building a house?

So to go back to the OP, whether the right tool is a matter of preference or not just depends on what your goals are. For example, a hobbyist writing code in his free time is likely just doing it for fun - in that case he uses whatever tools he enjoys using the most. Or take a college student doing a summer project: the best tool for him may very well be something new and unfamiliar that reduces his effectiveness and productivity - yet achieves his goals of learning new things.

So if you're a hobbyist who is only concerned about enjoying himself, who cares about how productive a tool makes you if it isn't fun? If you work for a software contracting company who writes code for clients, who cares if you enjoy using a particular tool if it's a detriment to meeting your deadlines and requirements? The right/best/suitable tool is the one that best fits your circumstances and meets your goals - there's really nothing more to it than that.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Sun Jul 01, 2012 4:05 am UTC

Sc4Freak wrote:So if you're a hobbyist who is only concerned about enjoying himself, who cares about how productive a tool makes you if it isn't fun? If you work for a software contracting company who writes code for clients, who cares if you enjoy using a particular tool if it's a detriment to meeting your deadlines and requirements? The right/best/suitable tool is the one that best fits your circumstances and meets your goals - there's really nothing more to it than that.

You're presupposing a false premise: that the "right" tool is determined subjectively. But that's not a helpful analysis at all. It's much better to ask "If I could learn any tool at all, which ones are best?" The answer is "Those tools that let you create more tools most effectively." Learn how compilers and interpreters work. Learn parsing. Learn metaprogramming. Learn to build embedded domain specific languages. This probably means using a functional language like Lisp, ML, or Haskell.

Lately I've been doing a lot of Matlab programming. I hate Matlab. I hate it more with every passing day. So I've been doing less and less programming directly in Matlab and more in Haskell, where I write Haskell programs to generate Matlab programs. This works well because my employer gets Matlab code, and I don't have to get my hands dirty. But the point is that my tools are superior in an objective sense.

As for game programming, try using XNA with F# and see what happens. At the very least, recognize there are "tools for right now" and "the right tools". That's not to say neither will change.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Sun Jul 01, 2012 4:23 am UTC

One of the reasons I like C++ is because I can [ab]use its features to invent syntax within my program. I wrote math libraries that almost allow me to use GLSL code in C++. I don't know if that's what you meant exactly, but it's very fun.

EDIT: fixed a repetitive redunant use of words.
Last edited by sourmìlk on Sun Jul 01, 2012 7:49 pm UTC, edited 1 time in total.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

Great Justice
Posts: 54
Joined: Sun Aug 15, 2010 5:28 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Great Justice » Sun Jul 01, 2012 6:18 am UTC

The best language or pattern or paradigm or algorithm, besides being efficient, is one which allows you to model your thoughts and communicate them for posterity as well as unambigiously control the machine.
There is a basic practical v ideal tradeoff argument which will influence the answer. See "The Rise of Worse is Better" essay.
It usually isn't Congress or the State that tries to abridge free expression or free speech, [...] actually, in the present situation, the main threat to expression comes from public opinion.
~Christopher Hitchens

User avatar
WarDaft
Posts: 1583
Joined: Thu Jul 30, 2009 3:16 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby WarDaft » Mon Jul 02, 2012 8:43 pm UTC

The Worse is Better essay doesn't really clearly define terms. 'Worse' might certainly be more fit from an evolutionary standpoint, but that doesn't necessarily make it better.

The right tool for a job is the tool made for that kind of job. If you need something that has to guarantee perfect security, bit level hacks are not acceptable. If you need absolutely bleeding edge performance right now, things automatic bounds checking and garbage collection are not acceptable. Maybe the only solution is to play with pointers in a highly critical inner loop in C (though that depends on how long Supercompliation takes to get rolling, if ever), or maybe you can just tell one of the appropriate Haskell libraries to derive whatever code to satisfy the type constraints you need.

In general, if two tools let you achieve the same net result, the one that lets the computer do more of the work for you is likely the one you should use if you can. You just have to count learning a new language as part of the work the compiler can't do. This is also one of the reasons why it's best to learn many languages.



But there definitely are better tools for different jobs, and we can pick two toy problems to demonstrate this. Consider building a simple Neural Network, vs a graphical pong web game. Both are pretty trivial with the right tool. If you ask me to make the first, I'm going to reach for Notepad++ and start tapping away at Haskell (ffnn sig net = flip (foldl (\x -> map (sig . sum . zipWith (*) x)) net -- for example) , the second, and I'm going to open up my Flash IDE. If you ask me to build a more complicated NN or webgame, the tools aren't likely to change.
All Shadow priest spells that deal Fire damage now appear green.
Big freaky cereal boxes of death.

somebody already took it
Posts: 310
Joined: Wed Jul 01, 2009 3:03 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby somebody already took it » Tue Jul 03, 2012 5:17 am UTC

Great Justice wrote:The best language or pattern or paradigm or algorithm, besides being efficient, is one which allows you to model your thoughts and communicate them for posterity as well as unambigiously control the machine.

I disagree. First I disagree with the idea of modeling our thoughts, I think we develop them with language rather than represent them. That is not to say that there are no thoughts outside of formal languages, but I think when we use our thoughts to generate language it shapes the thoughts to come.
A really stupid example; have you ever thought something, then realized it rhymed after the fact?
A more pertinent one:
If I were to program in C I would have to think about memory management. It is conceivable that it would be good to think about memory management. Perhaps it would inspire alternate architectures and new features for the program I write. But when I think about memory management, there is something else I could think about that I do not think about (at least not consciously).
Additionally, I disagree with the idea of ambiguity being a bad thing. It can be bad in some instances, but people rarely know exactly what they want. My ideal language would allow me to have something like a conversation with my computer where I provide some input, and it responds with some suggestions (i.e. auto-completion).

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Tue Jul 03, 2012 6:53 am UTC

somebody already took it wrote:
Great Justice wrote:The best language or pattern or paradigm or algorithm, besides being efficient, is one which allows you to model your thoughts and communicate them for posterity as well as unambigiously control the machine.

I disagree. First I disagree with the idea of modeling our thoughts, I think we develop them with language rather than represent them. That is not to say that there are no thoughts outside of formal languages, but I think when we use our thoughts to generate language it shapes the thoughts to come.

That's actually a really good point. This was one of the first things that struck me after I learned functional programming: I could think things that were previously forbidden to me. It's not that I could express myself in terms of maps and folds, but that whole avenues of thought had opened up. It's not just language features that new languages offer, but new ways of thinking. I take these things for granted now, and I wonder that I was ever bound by the constraints of Pascal or Java or C. (While C++ is doing a lot better in terms of language features, the syntax and "gotchas" still lead programmers toward certain methodologies and patterns.)

User avatar
freakish777
Posts: 354
Joined: Wed Jul 13, 2011 2:14 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby freakish777 » Thu Jul 05, 2012 6:48 pm UTC

@sourmìlk

Is your definition of best

"Most Profitable" ?

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Sat Jul 07, 2012 12:05 am UTC

freakish777 wrote:@sourmìlk

Is your definition of best

"Most Profitable" ?


That's actually another good question. What is the best definition of "best"? Does it depend on the situation? If so, how do definitions of "best" map to different situations?
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Is the Right Tool a Matter of Preference?

Postby Sc4Freak » Sat Jul 07, 2012 3:15 am UTC

sourmìlk wrote:
freakish777 wrote:@sourmìlk

Is your definition of best

"Most Profitable" ?


That's actually another good question. What is the best definition of "best"? Does it depend on the situation? If so, how do definitions of "best" map to different situations?

Well that's the point I was trying to make earlier in the thread - that it's precisely that "best" is something that depends entirely on your situation. If I'm running a shop full of PHP developers and I've got one month to create a web application, it's probably going to be easier and more efficient to use PHP on that project despite the fact that many people would agree that PHP is an awful language by many objective measures.

Ben-oni wrote:
Sc4Freak wrote:So if you're a hobbyist who is only concerned about enjoying himself, who cares about how productive a tool makes you if it isn't fun? If you work for a software contracting company who writes code for clients, who cares if you enjoy using a particular tool if it's a detriment to meeting your deadlines and requirements? The right/best/suitable tool is the one that best fits your circumstances and meets your goals - there's really nothing more to it than that.

You're presupposing a false premise: that the "right" tool is determined subjectively. But that's not a helpful analysis at all. It's much better to ask "If I could learn any tool at all, which ones are best?" The answer is "Those tools that let you create more tools most effectively." Learn how compilers and interpreters work. Learn parsing. Learn metaprogramming. Learn to build embedded domain specific languages. This probably means using a functional language like Lisp, ML, or Haskell.

Lately I've been doing a lot of Matlab programming. I hate Matlab. I hate it more with every passing day. So I've been doing less and less programming directly in Matlab and more in Haskell, where I write Haskell programs to generate Matlab programs. This works well because my employer gets Matlab code, and I don't have to get my hands dirty. But the point is that my tools are superior in an objective sense.

As for game programming, try using XNA with F# and see what happens. At the very least, recognize there are "tools for right now" and "the right tools". That's not to say neither will change.

Surely you're not trying to argue that the "right tool" is independent of your circumstances. Because that is definitely unhelpful.

I'm not saying that there aren't measures by which one tool can objective be better than another. Only that such measures can be irrelevant in the face of real-world requirements. If I make a living developing games for the iPhone, I'm sure I could go through the trouble of learning F# from scratch, then using XNA with it (an unsupported configuration) then use Mono to transcompile it into something that complies with Apple's marketplace policies. And I suppose I could forego the use of the multitudes of available game engines on the iPhone that use ObjC, like Unity or Unreal Engine and write everything myself from scratch.

But in the end, does that help me create a better game for less cost? I don't doubt that when wielded by an expert, a functional language like F# or Haskell will produce superior code with fewer defects compared to, say, C. After all, Haskell is famed for its ability to produce correct code ("if you get the types correct, the code is probably correct too"). But when you consider the practical aspects - the unfamiliar language and paradigms, the unsupported platform, the lack of tools and libraries - I'd have to be pretty mad to make that choice of tools when all I want is to be able to write this game as efficiently as possible.

You can take any example you want. Let's say I just inherited the job of maintaining a huge suite of CRM software for a large company. My job is to keep it running and working as cheaply as possible, but it has a spaghetti codebase with a million lines of Javascript that keeps track of data in a multi-gigabyte MS Access database (or "database" I should say). As is so often the case, it's extremely messy but it works and it just needs the occasional bugfix. It should be obvious that the solution in this case isn't to rewrite a million lines of working code with whatever the technology-du-jour is. Unless, of course, the cost of maintaining the software exceeded the cost of rewriting the thing.

I wasn't expecting that such an (apparently) uncontroversial statement would require so much explanation - I mean, it seems like an almost vacuous truth. But I'll state it again: the right tool for the job is the one which best helps you to achieve your goals. And I have yet to see any compelling argument otherwise.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Sat Jul 07, 2012 6:48 am UTC

Sc4Freak wrote:all I want is

There's that false premise again. When have programmers ever only wanted one thing? As a meta-programmer you can have it all. Yes you can use your favorite functional language to write games for iOS using whatever pre-existing game engines exist.

As for a shop full of PHP developers... I think a month is criminally optimistic, don't you?

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Is the Right Tool a Matter of Preference?

Postby Sc4Freak » Sat Jul 07, 2012 7:40 am UTC

Ben-oni wrote:
Sc4Freak wrote:all I want is

There's that false premise again. When have programmers ever only wanted one thing? As a meta-programmer you can have it all. Yes you can use your favorite functional language to write games for iOS using whatever pre-existing game engines exist.

So in other words the entirety of your premise rests on "programmers don't have well-defined goals"? :?

It seems that it's either that or you think "all programmers have the same goal". For the poor guy working the soul-crushing job writing plugins for a legacy Java enterprise application, I'm sure that he'll be delighted to hear that "he can have it all by becoming a meta-programmer" and that obviously his next step should be to spend his working hours creating DSLs which will never pay dividends for this project and which will probably get him fired for wasting company time and failing to produce his deliverables. But hey, that's an acceptable tradeoff, right?

As for a shop full of PHP developers... I think a month is criminally optimistic, don't you?

Probably. Meaning they don't have any time for retraining and relearning new tools and techniques. Maybe in the next cycle for their next project - when their circumstances and goals are different - they can take the time to invest in different tools and techniques which may eventually pay dividends in future projects. But in their current situation? Sticking with PHP would probably be absolutely the right choice. And for that group of developers, that may continue to be true indefinitely because the cost of retraining switching tools never outweighs the benefit.

Objective measures are useful, but are only one of the many inputs in determining whether any particular tool best suits your needs.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Sat Jul 07, 2012 8:00 am UTC

I'm a bit confused: what standard of "best" is Ben-Oni using?

Sc4Freak wrote: It should be obvious that the solution in this case isn't to rewrite a million lines of working code with whatever the technology-du-jour is.

It's not that obvious to me. >.>

But that's mostly because I can't stand using my own code when it's shitty, much less somebody else's. Unless I was explicitly instructed otherwise, I'd probably rewrite a code-base of any size if I had to work with it and I didn't like its design.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Is the Right Tool a Matter of Preference?

Postby Sc4Freak » Sat Jul 07, 2012 5:21 pm UTC

sourmìlk wrote:But that's mostly because I can't stand using my own code when it's shitty, much less somebody else's. Unless I was explicitly instructed otherwise, I'd probably rewrite a code-base of any size if I had to work with it and I didn't like its design.

I think that's really common - almost everyone feels like that. And the best part of a project is when there's some extra slack time or just after you've shipped - that's usually the time when you can go nuts and refactor/rewrite/clean up the code. :D

But wholesale rewriting something is actually usually a bad idea. Netscape tried it years ago, and we all know how well that turned out for them. Joel Spolsky wrote a good article on it.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Sun Jul 08, 2012 1:31 am UTC

I've read that article, and I'm sure that for practical purposes, rewriting is a bad idea. But for being-able-to-sleep-at-night purposes, it's better than ambien.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

User avatar
freakish777
Posts: 354
Joined: Wed Jul 13, 2011 2:14 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby freakish777 » Mon Jul 09, 2012 12:57 pm UTC

sourmìlk wrote:But for being-able-to-sleep-at-night purposes, it's better than ambien.


So is alcohol though...

lorb
Posts: 405
Joined: Wed Nov 10, 2010 10:34 am UTC
Location: Austria

Re: Is the Right Tool a Matter of Preference?

Postby lorb » Mon Jul 09, 2012 8:58 pm UTC

sourmìlk wrote:My dad (a computer scientist) says that this is all religion though: people treat their preferences as objectively correct, when they're just preferences


Yes, it is >80% religion. We even have conflicting religions right in this thread. (The 20% not being religion is things like brainfuck that are really not suited for some things.) HQ9+ is a humorous attempt at it :)
Please be gracious in judging my english. (I am not a native speaker/writer.)
http://decodedarfur.org/

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Mon Jul 09, 2012 11:43 pm UTC

lorb wrote:
sourmìlk wrote:My dad (a computer scientist) says that this is all religion though: people treat their preferences as objectively correct, when they're just preferences


Yes, it is >80% religion. We even have conflicting religions right in this thread. (The 20% not being religion is things like brainfuck that are really not suited for some things.) HQ9+ is a humorous attempt at it :)

I was trying to remember HQ9+ earlier in this thread, but it managed to slip away from me. For very particular problems*, the "language" makes them trivially easy to solve.

But that's neither hear nor there anymore. You've gone for the ">80%" religion argument, which is total bunk. If that were true, no one would bother learning more languages. I can say that because of how you described the other <20%. Why learn SQL when you already know PHP**? Why learn LEX and YACC when you already know C***? Sure, we could adopt the Microsoft Philosophy™: Design the perfect language and runtime system, and force everyone to use it. Then no one will need anything else, ever, and compatibility will be assured forever. And then somebody has a use-case that the language performs poorly for. What a mire!

So, no. It's not religion. It's about using the right tool for the job! VB will never be on equal footing with other languages. Matlab will never be useful for production code. Pascal is too clumsy to be seriously used. COBOL is... praise whatever deity you worship if you don't have to work with that tarpit****, and pray you never need to.

I mean, you say brainf*ck is objectively worse than other languages (for the sake of argument, let's say C). But it has some things going for it, doesn't it? For instance, it's highly portable. It also has some things ranking against it: it's very hard to read and reason about. So, just what pushes it into the Turing Tarpit? The lack of abstraction capabilities. C lets you define functions while brainf*ck doesn't, meaning you can't abstract anything. Perhaps there's a ranking of languages by abstraction capabilities somewhere. There's probably a continuum with the Turing Machines at the bottom and Lisp***** at the top. It's probably more like a lattice, in all honesty—a partial ordering of languages, if you will.

Let's just look at C vs. C++. Most programmers use C++ over C, right? Why? Because it offers better tools for abstraction (classes, templates, etc). Then consider who uses C: the Unix/Linux gods who need to get as close to the silicon as they can. The use of C, though, is probably more for historical reasons, and Unix/Linux has been in maintenance mode for an epoch, so they're not scrambling for change.

Now, why C++0x? If it's just a religious war, why did they add lambda expressions and implicit typing? Because functional programming offers more levels of abstraction—useful abstractions for the real world—that C++ developers want to use. I suspect the next generation of C++ developers will decide they don't want to deal with memory allocation anymore. Pointer arithmetic will go "buh-bye", and full-fledged garbage collection will be introduced******.

Last of all, a look from the Lisp perspective: Start with Assembler. Write everything in s-expressions. Choose a half-way decent notation for functions and write library functions for providing cons cells and automatic reclamation of those memory units. Add symbols and defmacro. It's not a huge step to add lambdas from there, to let macros call user-defined functions, etc. Soon, you have a Lisp without having stepped far off the assembler base. The Lisper will argue that everything is a Lisp—it just doesn't know it yet. More accurate is the observation that Lisp is great for metaprogramming, ever in other languages, because of the level of abstraction it offers.

And, just to nip the arguments about language popularity in the bud, I'll add that I've had people argue the merits of languages like APL to me, even in today's modern environment (and I'm not talking about derivatives like J or K). Large software companies invest a great many resources to get momentum behind their platforms: Apple pushes Objective-C, Sun pushed Java like nobodies business, Microsoft has a lot behind VB and C#. The same can be said for other languages: COBOL was the language for business applications, Fortran was what real hackers used*******, and the only reason programmers didn't use raw Assembler was because their brains had rot from too much Lisp.

So, maybe there's some religion in the debate (<20%), but for the most part, there are objectively better and worse languages.


*By some queer definition of "problem". Nothing that HQ9+ can do solves anything in need of a solution, of course.
**Because PHP doesn't actually do anything otherwise.
***Because C isn't suitable for describing parsers.
****Hyperbole, but not by much.
*****Or so the Lisper's argue.
******They won't call it C++ anymore, of course. Maybe Objective-C++. No, wait!
*******For some definition of "real hackers".
Last edited by Ben-oni on Tue Jul 10, 2012 8:18 pm UTC, edited 1 time in total.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby EvanED » Mon Jul 09, 2012 11:51 pm UTC

Ben-oni wrote:Why learn LEX and YACC when you already know C***?
...
***Because C isn't suitable for describing parsers.

FWIW and speaking of religion, for a variety of reasons at this point I'd rather write a recursive descent parser in C than use Lex and Yacc, in virtually any situation.

User avatar
headprogrammingczar
Posts: 3072
Joined: Mon Oct 22, 2007 5:28 pm UTC
Location: Beaming you up

Re: Is the Right Tool a Matter of Preference?

Postby headprogrammingczar » Tue Jul 10, 2012 12:03 am UTC

If all I had was C, I would write a bootstrapping compiler for GHC and use Parsec...

pretend you don't need a parser to write a bootstrapper...
<quintopia> You're not crazy. you're the goddamn headprogrammingspock!
<Weeks> You're the goddamn headprogrammingspock!
<Cheese> I love you

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Tue Jul 10, 2012 12:24 pm UTC

Ben-Oni, just because the proper choice is mostly religion doesn't mean that learning different languages doesn't have value. Just because it's mostly religion which language you choose to use doesn't mean you don't have to use different languages for different problems. It doesn't mean that every language is appropriate for every problem, it just means you have a lot of choice.

Also, C doesn't necessarily get you any closer to the hardware than C++ does. C++ is almost exactly a superset of C, so if you don't use certain features / libraries of C++, you can have exactly as much control as you do in C. You might think "Well if you're not using the C++ features of C++ then you're basically just programming in C, so that's a stupid distinction", but there are features in C++ that don't exist in C and that don't distance you from the hardware. It's just that C++ doesn't necessarily abstract you from the hardware more than C does, unlike (for example) python which necessarily will.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

lorb
Posts: 405
Joined: Wed Nov 10, 2010 10:34 am UTC
Location: Austria

Re: Is the Right Tool a Matter of Preference?

Postby lorb » Tue Jul 10, 2012 5:37 pm UTC

Ben-Oni, after reading your post i see that i should have explained my point of view a little better. I still maintain that choice or preference of a programming language is mostly religion (or taste). The question why one would still learn SQL after already knowing PHP ist to me kind of the same as the question why one does not write game-engines in brainfuck. It's either just plain impossible to do things SQL can in PHP (or write a game-engine in BF) or that hard/complicated that doing it would require at least 10 times the effort than to learn a new language and do whatever you want with that. That's the 20% and they are really common sense. Obviously a special-purpose programming language that is designed to do a certain thing will be good at it and it will be easy to use it, but it is extremely rare that for any given purpose only one language exists and which one of the available ones you choose is the 80%. (Also most tasks don't require a special-purpose language, and there are tons of general-purpose languages and if you look at the typical java vs c++ debate or something similar the 80% religion estimate is still way too low.) I also want to stress the point sourmilk makes: It doesn't mean that every language is appropriate for every problem, it just means you have a lot of choice.
Please be gracious in judging my english. (I am not a native speaker/writer.)
http://decodedarfur.org/

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Tue Jul 10, 2012 8:17 pm UTC

lorb wrote:Ben-Oni, after reading your post i see that i should have explained my point of view a little better. I still maintain that choice or preference of a programming language is mostly religion (or taste). The question why one would still learn SQL after already knowing PHP ist to me kind of the same as the question why one does not write game-engines in brainfuck. It's either just plain impossible to do things SQL can in PHP (or write a game-engine in BF) or that hard/complicated that doing it would require at least 10 times the effort than to learn a new language and do whatever you want with that. That's the 20% and they are really common sense. Obviously a special-purpose programming language that is designed to do a certain thing will be good at it and it will be easy to use it, but it is extremely rare that for any given purpose only one language exists and which one of the available ones you choose is the 80%. (Also most tasks don't require a special-purpose language, and there are tons of general-purpose languages and if you look at the typical java vs c++ debate or something similar the 80% religion estimate is still way too low.) I also want to stress the point sourmilk makes: It doesn't mean that every language is appropriate for every problem, it just means you have a lot of choice.

You're still not understanding. There was a point I deliberately didn't address before: general purpose vs. special purpose languages. For the sake of rhetoric, I mixed and matched a bit. Let me be clear. I'll bold this so you don't get confused: General purpose programming languages are not created equal. CL is not the same as Haskell is not the same as C++ is not the same as Perl is not the same as Python. Use the appropriate language for the appropriate task.

Since it was already mentioned, I'll illustrate with the C++ vs. Java comparison. There's no point arguing which is better, because the two have completely different use cases. C++ compiles to the native platform, Java runs on an inner platform. Use Java only when you need the benefits of that inner platform. There are a lot of things to like about the Java platform: the virtual machine can run on almost any hardware, code can be loaded dynamically from any source and run without compromising system security, etc. Using it to build a desktop application (like OpenOffice, which has fortunately fallen out of favor) would be considered an anti-pattern.


sourmìlk wrote:C++ is almost exactly a superset of C

No, it is not. This statement reveals incredible naivete. I take it you've never used nested functions in C? Of course not, you only know C++. C++11 mitigates the feature issue, but does it in a way that makes the languages quite distinct.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby EvanED » Tue Jul 10, 2012 8:27 pm UTC

Ben-oni wrote:No, it is not. This statement reveals incredible naivete. I take it you've never used nested functions in C?

Um, C doesn't have nested functions.

Maybe you mean some GNU bastardization of C?

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Tue Jul 10, 2012 8:42 pm UTC

EvanED wrote:
Ben-oni wrote:No, it is not. This statement reveals incredible naivete. I take it you've never used nested functions in C?

Um, C doesn't have nested functions.

Maybe you mean some GNU bastardization of C?


It's a GNU C extension.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 11, 2012 6:07 am UTC

Ben-oni wrote:No, it is not. This statement reveals incredible naivete. I take it you've never used nested functions in C? Of course not, you only know C++. C++11 mitigates the feature issue, but does it in a way that makes the languages quite distinct.


Let's ask Bjarne Stroustrup, the creator of C++:

Bjarne Stroustrup wrote:In the strict mathematical sense, C isn't a subset of C++.

This may seem to support your point, but recall that I said that C++ was almost a superset of C. He goes on to say:
Bjarne Stroustrup wrote:Well written C tends to be legal C++ also.

...

Except for a few examples ... C++ is a superset of C.


So yeah, C++ is almost a superset of C, according to the creator of C++.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Is the Right Tool a Matter of Preference?

Postby Sc4Freak » Wed Jul 11, 2012 6:40 am UTC

It's probably more correct to say "C++03 is almost a strict subset of C89", because since C99 there have been a couple of divergences (which may have been reconciled in C++11? Not sure about that one). But in C89 there are only a few differences that prevent it from being a strict subset of C++03 and newer. Obviously C++ has more keywords and reserved identifiers than C, and its pointer conversion rules are stricter too (no implicit casts between unrelated types). C's linkage rules are also a bit... strange. But I can't really think of any other differences beyond those - generally speaking, valid C is also mostly valid C++.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby EvanED » Wed Jul 11, 2012 7:16 am UTC

Sc4Freak wrote:generally speaking, valid C is also mostly valid C++.

It depends on how you count. For example, I'd assert that while almost all C code by # of statements and such has the same meaning in C++, I'd also assert that almost no C projects would actually compile with a C++ compiler. (How many C projects either never call malloc or explicitly cast the return? I bet that's a tiny proportion...)

So it depends on how you count.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 11, 2012 7:48 am UTC

malloc and the C standard library are valid in C++.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

User avatar
jaap
Posts: 2094
Joined: Fri Jul 06, 2007 7:06 am UTC
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby jaap » Wed Jul 11, 2012 8:10 am UTC

sourmìlk wrote:malloc and the C standard library are valid in C++.

The point is that in C it is not necessary to cast the void* return value of a malloc, because C has implicit conversion of void pointers. Unnecessary casts are generally frowned upon because such casting can lead to subtle errors if the cast is wrong*, and so normal C style will not use the cast.
C++ does not have implicit conversion of void pointers, so casting the return value of a malloc is mandatory and not doing so would lead to compile errors.

In other words, while it is possible to write C programs that also compile as C++ programs, the most common C style of coding does not in general lead to such a program.

* Edit: or if you forgot to include stdlib.h or other declaration of the malloc signature.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Wed Jul 11, 2012 8:45 am UTC

The linkage rules are actually pretty significant in terms of divergence. From a language perspective (and I seem to remember this having been a language discussion at some point?) C++ has all the language features that C has. So I'm in agreement there. This is, of course, the crux of the argument. Does adding features to a language add to it's suitability as a general purpose language, or detract from it? Considering some of the "features" of perl, and how its practitioners are almost (did I say almost?) proud that perl code is almost (I used that word again?) always unintelligible, even to the original coder, there may be a point to be made here. There's also been discussion over the years about "maintainable perl", but no one has ever been able to provide evidence of this mythical creature. It has been observed in captivity a few times, but almost (why do I keep saying that?) never in the wild. Regardless, most of the time, when a language offers mechanisms for abstraction, it's to increase the usefulness and suitability of the language.

As for using C vs. C++, there are times when it's important. For instance, Objective-C also claims to be a superset of C (at least in the same sense C++ is). Because it has its own class system that is incompatible with C++'s system, so-called Objective-C++ is an awkward affair, though the compiler does its best. Now imagine trying to develop an application simultaneously for OS X and Windows: C# plays friendly with C++ but not C (though MSC++ will play friendly with C!), while Objective-C (because if you want a native looking app, you'll need Cocoa) plays friendly with C but not C++. At the very bottom, you'll have to use C linkage before interfacing with the OS. Or maybe there's a better solution. The gist of it is that when it comes to FFI, C linkages are more widely supported than C++, though this probably just results in extern "C" {...} blocks within C++ headers.


Return to “Coding”

Who is online

Users browsing this forum: Steeler [Crawler] and 6 guests