www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template Metaprogramming Made Easy (Huh?)

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/9iidr/template_metaprogramming_made_easy_huh/
Sep 08 2009
parent reply Justin Johansson <procode adam-dott-com.au> writes:
Well I've been groking D for the best part of a mere 10 days now so I wouldn't
like to make a naive comment but these my (random but related to this thread)
thoughts so far ...

D is to C++ as Scala is to Java.

Always thought that constructors were tuples in disguise.  Was surprised to
find that D is one of the few languages to realize it .. and, boy, not just
value tuples, type tuples as well!  What a boon for meta-programming.

The very articulate Paul Graham writes in "The Hundred-Year Language"
http://www.paulgraham.com/hundred.html
"Though the situation is better in the sciences, the overlap between the kind
of work you're allowed to do and the kind of work that yields good languages is
distressingly small. ... types seem to be an inexhaustible source of research
papers, despite the fact that static typing seems to preclude true macros--
without which, in my opinion, no language is worth using."
If I'm not mistaken, (LISP) macros**, metaprogramming, templates are different
views of the same thing and any language which makes template metaprogramming
easy is definitely worth it.
** Yes I know, there is nothing as pure as LISP macros but since I tend to lead
a rather impure life 'D' has my attention now.

Given Martin Odersky awarded top ACM recognition
http://actualites.epfl.ch/index.php?module=procontent&func=display&id=2046
for Scala, FP etc, perhaps Walter Bright should be considered for a Fields
Medal for D :-)
http://en.wikipedia.org/wiki/Fields_Medal

Lest this newsgroup slip into being just mutual appreciation society forum, I'd
suggest that the seasoned D gurus go forth and evangelize the language by
commenting back on that Reddit link.
http://www.reddit.com/r/programming/comments/9iidr/template_metaprogramming_made_easy_huh/

I really really hope that my current excitement with D continues and that
another 30-60 days down the track I don't end up becoming disillusioned with D
as I did with Scala.

-- Justin Johansson 
Sep 08 2009
next sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Justin Johansson Wrote:
 I really really hope that my current excitement with D continues and that
another 30-60 days down the track I don't end up becoming disillusioned with D
as I did with Scala.
 
 -- Justin Johansson 

I've been using D for over 2 years now, and my excitement about it still continues to grow :)
Sep 08 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Justin Johansson wrote:
 Lest this newsgroup slip into being just mutual appreciation society
 forum, I'd suggest that the seasoned D gurus go forth and evangelize
 the language by commenting back on that Reddit link. 
 http://www.reddit.com/r/programming/comments/9iidr/template_metaprogramming_made_easy_huh/

So do I, especially your comments!!!
Sep 08 2009
parent reply Justin Johansson <procode adam-dott-com.au> writes:
Walter Bright Wrote:

 Justin Johansson wrote:
 Lest this newsgroup slip into being just mutual appreciation society
 forum, I'd suggest that the seasoned D gurus go forth and evangelize
 the language by commenting back on that Reddit link. 
 http://www.reddit.com/r/programming/comments/9iidr/template_metaprogramming_made_easy_huh/

So do I, especially your comments!!!

You're welcome, Walter, and whilst I tend to fear of being flamed in a public forum (I don't have a thick enough skin to be a politician), I tried to practice, and not just preach, by making my own contribution to the reddit discussion a short while ago. Anyway since I'm a newcomer here it might help if I introduce myself so people know where I'm coming from. Like yourself, I have a formal engineering degree. Read in your bio that you originally did mechanical eng whereas I did electrical eng and with love of maths and physics. Like you I went from engineering to exclusively software. That being circa 1982, I'm from the older crowd. (Surprise .. read your comment somewhere that D tends to appeal to the younger crowd.) Have degree in computer science as well .. back when Fortran was on the Control Data 6400 menu .. shortly before birth of Vax and Wirth producing that pedagogical language, Pascal. Got into software via electronics and microprocessors - 8085, SCAMP (first 16-bit microprocessor based on Data General Nova minicomputer architecture), 6809 and later 68020 and Texas Instruments TMS32010 digital signal processor. Developed multitasking executive for Z80 and 68020 for real-time scientific instrumentation in assembler and C. Got into OO with Smalltalk and with birth of C++ compilers, notably Zortech C++. After 15+ years in C++ world, 3-4 years ago was forced into a Java labour camp due to diminishing requirements for C++ skills in the local job market. Always felt that somehow I missed out on the Baroque era of LISP and FP but looks like there's a Renaissance happening now with new languages like Clojure and Scala. D looks like getting there too (FP-wise I mean, though agree with other writer on this thread that Scala is currently perhaps a little more FP-friendly). However what's attracting me to D now is its pragmatism and it not being "governed by a corporate agenda or any overarching theory of programming" to quote the DM intro page. For me D represents an opportunity to reach back to my roots in bare metal systems programming in a modern setting. For the moment though, for stability and license reasons, I've decided to stick with DMD 1.0 and Phobos for a new project that I'm working on. Linux platform btw. Cheers Justin Johansson
Sep 08 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Justin Johansson wrote:
 You're welcome, Walter, and whilst I tend to fear of being flamed in
 a public forum (I don't have a thick enough skin to be a politician),
 I tried to practice, and not just preach, by making my own
 contribution to the reddit discussion a short while ago.

I noticed, and thanks! Also thanks for the bio. It's nice to put a little flesh on the bones of those who post here, so to speak :-)
Sep 09 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Justin Johansson:

D is to C++ as Scala is to Java.<

Scala allows to write shorter programs compared to Java ones, is more flexible and more complex than Java. D2 is less complex than C++, it's a bit less verbose than C++, and a bit less flexible than C++. (Both Scala and D add some functional sides to their older languages. Scala is currently more functional-friendly than D2). Paul Graham:
static typing seems to preclude true macros<

Paul knows Lisp well, but I don't believe in that statement. I'll read more about this.
If I'm not mistaken, (LISP) macros**, metaprogramming, templates are different
views of the same thing<

Lisp macros are quite more powerful than C++-style templates. Time ago Walter was interested in adding AST (compile-time only) macros to D, but I think he's not interested in adding them any more.
 ** Yes I know, there is nothing as pure as LISP macros but since I tend to
lead a rather impure life 'D' has my attention now.<

CLisp macros are not pure at all, Scheme macros are a bit less dirty :-)
I don't end up becoming disillusioned with D as I did with Scala.<

I don't program in Scala, and overall it's probably not my ideal language at all, but I think it's a cute language (and the JavaVM it runs on has some good things, like its GCs, some inlining/profiling code, etc), and I believe it has some lessons to teach to D developers. Can you tell me/us why you think Scala was not good enough for you? Bye, bearophile
Sep 08 2009
parent reply Justin Johansson <procode adam-dott-com.au> writes:
Hi bearophile,

I'm not sure that I want fuel the language wars but curiously I notice you say

"I don't program in Scala"

but in http://www.mail-archive.com/digitalmars-d puremagic.com/msg15946.html

you (allegedly) say

- to summarize: I use Scala for high level tasks, and came back to D when I 
need to see the actual machine code and optimize some tight inner loop. D is 
sometimes more suitable for this than C/C++ since it has a bit saner syntax 
and high level abstractions. But in general I nowadays write 90% of my code 
in Scala. I'm much happier and more productive writing Scala. YMMV

Has something changed for you re Scala since you wrote this?

Justin Johansson
Sep 08 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Justin Johansson:
you (allegedly) say<

Nope, look better, those words are written by Jari-Matti M.. Bye, bearophile
Sep 09 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Sep 8, 2009 at 8:40 PM, Justin
Johansson<procode adam-dott-com.au> wrote:

 Got into OO with Smalltalk and with birth of C++ compilers, notably Zortech
C++.

Then you've had experience with Walter's compilers before ;) He wrote Zortech.
Sep 08 2009
prev sibling next sibling parent reply language_fan <foo bar.com.invalid> writes:
Tue, 08 Sep 2009 17:25:08 -0400, Justin Johansson thusly wrote:

 D is to C++ as Scala is to Java.

The word you are looking for may be 'successor'.
 The very articulate Paul Graham writes in "The Hundred-Year Language"
 http://www.paulgraham.com/hundred.html "Though the situation is better
 in the sciences, the overlap between the kind of work you're allowed to
 do and the kind of work that yields good languages is distressingly
 small. ... types seem to be an inexhaustible source of research papers,
 despite the fact that static typing seems to preclude true macros--
 without which, in my opinion, no language is worth using." If I'm not
 mistaken, (LISP) macros**, metaprogramming, templates are different
 views of the same thing and any language which makes template
 metaprogramming easy is definitely worth it. ** Yes I know, there is
 nothing as pure as LISP macros but since I tend to lead a rather impure
 life 'D' has my attention now.

I do not know what is so pure in LISP's macros. Macro is a "pure" evaluation function that takes a meta-program and outputs another program that can be compiled to an executable (or interpreted). The larger difference is that macros in LISP are cleaner since they allow modifying all code as data. The lack of type system is another thing. A type system for meta-language has non-trivial requirements and I have to say that the most general system in D (string mixins) is not that large an improvement over LISP's macros. Go and see how template haskell did the same..
 Given Martin Odersky awarded top ACM recognition
 http://actualites.epfl.ch/index.php?

 for Scala, FP etc, perhaps Walter Bright should be considered for a
 Fields Medal for D :-) http://en.wikipedia.org/wiki/Fields_Medal

Martin is a computer scientist, Walter is an engineer. Martin creates new science, Walter just applies existing knowledge. Those awards are only meant for real scientists - engineers have their own award systems.
Sep 09 2009
parent Justin Johansson <procode adam-dott-com.au> writes:
language_fan Wrote:

 Tue, 08 Sep 2009 17:25:08 -0400, Justin Johansson thusly wrote:
 ** Yes I know, there is
 nothing as pure as LISP macros but since I tend to lead a rather impure
 life 'D' has my attention now.

I do not know what is so pure in LISP's macros. Macro is a "pure" evaluation function that takes a meta-program and outputs another program

I put that caveat in there to avoid being flamed by religious LISPers. It was a "diplomatic" concession. The argument I've often seen regarding LISP style macros is that they let you directly manipulate the AST which is why they (well some of them) think macro systems in other PLs are a poor imitation of the one true LISP macro. :-)
 
 for Scala, FP etc, perhaps Walter Bright should be considered for a
 Fields Medal for D :-) http://en.wikipedia.org/wiki/Fields_Medal

Martin is a computer scientist, Walter is an engineer. Martin creates new science, Walter just applies existing knowledge. Those awards are only meant for real scientists - engineers have their own award systems.

Indeed; wasn't meant to be taken too literally; poetic license; my friend's brother has a Fields Medal so I'm well aware what this is.
Sep 09 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Tue, 08 Sep 2009 18:09:01 -0400, bearophile thusly wrote:

 CLisp macros are not pure at all, Scheme macros are a bit less dirty :-)

Even though conversation on this newsgroup is mostly bikeshedding, it is wrong to use confusing new unestablished terms like dirtyness. The correct word is hygiene, and there is even a wikipedia page for all you folks who have forgotten what it means: http://en.wikipedia.org/wiki/ Hygienic_macro
Sep 09 2009
prev sibling next sibling parent reply language_fan <foo bar.com.invalid> writes:
Thu, 10 Sep 2009 03:21:10 -0400, Nick Sabalausky thusly wrote:


 I really really hope that my current excitement with D continues and
 that another 30-60 days down the track I don't end up becoming
 disillusioned with D as I did with Scala.

What did you dislike about it?

At least the problem with many old-school developers is that even though a new language is 10x more readable, 100x more flexible, 1000x safer and 10000x faster to develop with, if it's 0.1% slower than C++, they have no reason to use it. Well, it shouldn't be a surprise given that JVM *is* a VM.
Sep 10 2009
parent reply #ponce <aliloko gmail.com> writes:
 At least the problem with many old-school developers is that even though 
 a new language is 10x more readable, 100x more flexible, 1000x safer and 
 10000x faster to develop with, if it's 0.1% slower than C++, they have no 
 reason to use it. Well, it shouldn't be a surprise given that JVM *is* a 
 VM.

So I'm a 22 yo oldschool developer. One reason I hate VM language is not really about speed but that you have few control on what the CPU do, and very few control over memory and cache usage. Compound value types also are often lacking (especially in Java). See python internal objects size : http://www.codexon.com/posts/memory-size-of-python-objects Everything takes 4x the memory it would take in D. Each field access seems to be a lookup into a hashmap. This is plain ugly. Also, when some part of a program is slow in C / C++ / D, most of time you have a way to speed it up. It may be painful but there is one.
Sep 10 2009
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
language_fan wrote:

(...)
 
 For what's it worth, I have not seen any firmware projects that use D,
 either. Not that it's impossible, no one in the firmware industry just is
 not interested in D. When you have limited amount of memory resources,
 the bloaty executables that dmd generates (all firmware uses x86 opcodes,
 right), the typeinfos, and the garbage collector are a nuisance.
 

If you don't mind me asking, what is your interest in D?
Sep 10 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
language_fan wrote:
 Fri, 11 Sep 2009 09:34:54 +0200, Don thusly wrote:
 
 dsimcha wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 In general though, I find the "programmer time is more expensive than
 hardware" line to largely be a cop-out.

getting cheaper relative to programming time. This is obvious to anyone who doesn't live under a rock. My previous post was pointing out how this is relevant in case that was less obvious.

ends up costing you in the long term. Good quality code gets reused.

Another point related to maintenance costs is the choice of language. Many smaller companies choose "easier" languages like php, visual basic, or python for their applications because they outsource library writing and it is much cheaper and easier to hire new workforce for business logic when the existing codebase does not use any complex idioms or language constructs. Some indian schoolboy can write e.g. php pages $1-2/ h, a hard-core C++/Haskell professional easily costs $500/h.

Haven't heard of many $500/h gigs. Andrei
Sep 11 2009
parent Justin Johansson <procode adam-dott-com.au> writes:
 Another point related to maintenance costs is the choice of language. 
 Many smaller companies choose "easier" languages like php, visual basic, 
 or python for their applications because they outsource library writing 
 and it is much cheaper and easier to hire new workforce for business 
 logic when the existing codebase does not use any complex idioms or 
 language constructs. Some indian schoolboy can write e.g. php pages $1-2/
 h, a hard-core C++/Haskell professional easily costs $500/h.

Haven't heard of many $500/h gigs. Andrei

I have. Haven't you every been to see a lawyer :-) Seriously, the OP must have meant $500/day.
Sep 11 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Thu, 10 Sep 2009 04:18:58 -0400, #ponce thusly wrote:

 At least the problem with many old-school developers is that even
 though a new language is 10x more readable, 100x more flexible, 1000x
 safer and 10000x faster to develop with, if it's 0.1% slower than C++,
 they have no reason to use it. Well, it shouldn't be a surprise given
 that JVM *is* a VM.

So I'm a 22 yo oldschool developer. One reason I hate VM language is not really about speed but that you have few control on what the CPU do, and very few control over memory and cache usage. Compound value types also are often lacking (especially in Java).

Nowadays when everyone soon has 12-core CPUs in front of them, especially x86-64 ones, managing each register and memory module (cache or main memory) manually is a major pain in the ass. Why do you want to do that in the first place? For greater speed? The problem is, your program usually has tons of memory leaks, potential race conditions and deadlocks, and states where is segfaults. Even if you develop for free, I do not want to use your buggy pos. YMMV
 Also, when some part of a program is slow in C / C++ / D, most of time
 you have a way to speed it up. It may be painful but there is one.

So you are part of the efficiency is priority #1 subgroup, after all. There is nothing wrong with that, I just happened to guess that.
Sep 10 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Thu, 10 Sep 2009 04:18:58 -0400, #ponce thusly wrote:

 See python internal objects size :
 http://www.codexon.com/posts/memory-size-of-python-objects Everything
 takes 4x the memory it would take in D. Each field access seems to be a
 lookup into a hashmap. This is plain ugly.

Python is not the only language running on a VM, you know. Your comparison would be fairer if you happened to choose a statically typed language such as Java, which is a bit more performance oriented. If you have time, you can try to build a python compiler that compiles to native code *without* resorting to damn slow hashmaps.
Sep 10 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Thu, 10 Sep 2009 06:05:59 -0400, Nick Sabalausky thusly wrote:

 "#ponce" <aliloko gmail.com> wrote in message
 news:h8acpi$21u1$1 digitalmars.com...
 At least the problem with many old-school developers is that even
 though a new language is 10x more readable, 100x more flexible, 1000x
 safer and 10000x faster to develop with, if it's 0.1% slower than C++,
 they have no reason to use it. Well, it shouldn't be a surprise given
 that JVM *is* a VM.

So I'm a 22 yo oldschool developer. One reason I hate VM language is not really about speed but that you have few control on what the CPU do, and very few control over memory and cache usage. Compound value types also are often lacking (especially in Java). See python internal objects size : http://www.codexon.com/posts/memory-size-of-python-objects Everything takes 4x the memory it would take in D. Each field access seems to be a lookup into a hashmap. This is plain ugly. Also, when some part of a program is slow in C / C++ / D, most of time you have a way to speed it up. It may be painful but there is one.

use them for systems programming (ex, try using Java or Python to write firmware

For what's it worth, I have not seen any firmware projects that use D, either. Not that it's impossible, no one in the firmware industry just is not interested in D. When you have limited amount of memory resources, the bloaty executables that dmd generates (all firmware uses x86 opcodes, right), the typeinfos, and the garbage collector are a nuisance. , or a commercially-competetive NDS game. And what language is a
 person going to use to implement that VM in? Another VMed langauge? That
 would be pointless). Now, for some people that's not an issue, because
 they may never venture outside of web development and maybe end-user
 desktop apps (Hell, most of the programmers I've met here in Cleveland
 would never be *capable* of going beyond such simple types of
 software...but that's a whole other set of discussions...).

I happen to know that for instance the code (written in e.g. Java) banking industry, online shops, and web search engines use, isn't quite the simplest type of software. You can ask amazon or google or the technical department of your favorite bank. They wouldn't use C++ or D in its current form for the majority of their tasks, it's just how it is. The problem with many developers is that they refuse to understand the mathematics behind algorithms. Time complexity just happens to matter more when you have millions of clients etc. If Java is 50% slower, it doesn't matter when your algorithm is 4 orders of magnitude faster with 10 million clients. Writing good algorithms is quite hard and error prone in low level languages and that's why bad algorithms are usually used even if they are known to perform weakly.
Sep 10 2009
prev sibling next sibling parent reply language_fan <foo bar.com.invalid> writes:
Thu, 10 Sep 2009 16:49:47 -0400, Nick Sabalausky thusly wrote:

 "language_fan" <foo bar.com.invalid> wrote in message

 Nowadays when everyone soon has 12-core CPUs in front of them,
 especially x86-64 ones, managing each register and memory module (cache
 or main memory) manually is a major pain in the ass.

That's just plain arrogant and ignorant. I swear, the next time I see yet another person pulling out the "That's all they offer in the stores, therefore that must be only thing that's actually in use, and if anyone uses less, well then screw them for not being as big of a consumer whore as I am" bullshit, my head's going to explode.

If I go to a store, the cheapest computer I can buy has a dual core cpu - that's just how it is. The $500..600 class computers have quad cores. Even the $100..200 range netbooks soon have (if they don't yet) dual cores. If we assume that most computers just break down in 2-5 years, we will pretty soon have only multi-core computers left. My old Pentium 2 is already quite dead and the motherboard in my Athlon XP 2000+ broke down last year. I've given away all older machines. I really don't expect them to be functional or usable these days.
 Plus...what in the world makes you think VMed languages don't get
 errors, memory leaks, and race conditions? Segfaults I'll grant you, but
 that's hardly any different for the end-user than an unhandled
 exception.

There are couple of things a VM fixes. Not all of them, but some. Switching to a safer languages helps even more. I don't like C++.
Sep 10 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Nick Sabalausky (a a.a)'s article
 And before I get the inevitable "D00d thats soo old U shud by a new 1!",
 yes, I *could* go buy a new system. But why should I? I don't do a single
 thing that can't be done just fine on my single-cores. And the only things
 that run poorly are the things are written by teenage lazy hack "I don't
 care about intelligent coding, because everyone should be just like me and
 want to sink all their money into new hardware just because they can!"

Not sure I buy this. Let's analyze it in simple microeconomics. Both programmer time and computer hardware are scarce, expensive commodities. To some extent, one can be substituted for the other. (A programmer can either spend less time writing crappier code that needs more hardware or vice-versa.) All else being equal, you want the cheapest software you can get. For the sake of this argument, I'm going to assume that the software is paid for directly by the consumer, though the argument could be extended to cases where it is paid for indirectly (business websites, etc.) and free software. A company can either deliver really unoptimized software for little programmer time, and thus cheaply, or really fast software expensively. As a consumer, you only care about *total* cost. Therefore, as the cost of better hardware goes down, the only rational thing to do is spend less time optimizing software. Of course, this doesn't work for special purpose computers that only run one piece of software, but let's say the average computer user runs ~20 pieces of software regularly. If a new computer costs $400, and each piece of software can be made on average $20 cheaper by not optimizing it, then you break even.
Sep 10 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Nick Sabalausky (a a.a)'s article
 In general though, I find the "programmer time is more expensive than
 hardware" line to largely be a cop-out.

Fair enough, but can you elaborate on this? Of course hardware is getting cheaper relative to programming time. This is obvious to anyone who doesn't live under a rock. My previous post was pointing out how this is relevant in case that was less obvious.
Sep 10 2009
next sibling parent Don <nospam nospam.com> writes:
dsimcha wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 In general though, I find the "programmer time is more expensive than
 hardware" line to largely be a cop-out.

Fair enough, but can you elaborate on this? Of course hardware is getting cheaper relative to programming time. This is obvious to anyone who doesn't live under a rock. My previous post was pointing out how this is relevant in case that was less obvious.

Probably because you need to consider maintenance time. Poor quality ends up costing you in the long term. Good quality code gets reused. OTOH the age where performance matters, may be coming to an end. I hope not, because I always considered optimization to be one of the most interesting things about programming. But it's already becoming a niche market.
Sep 11 2009
prev sibling next sibling parent BCS <none anon.com> writes:
Hello dsimcha,

 == Quote from Nick Sabalausky (a a.a)'s article
 
 In general though, I find the "programmer time is more expensive than
 hardware" line to largely be a cop-out.
 

getting cheaper relative to programming time. This is obvious to anyone who doesn't live under a rock. My previous post was pointing out how this is relevant in case that was less obvious.

Always be VERY careful when you compare cost that are paid by different people. For programming, the better the product does, the more irrelevant programmer times is. To boot, programmer time is a more or less fixed cost (you can stop paying it any time you want), and slow code is an open ended one (your customers will be paying for it until the last person quits using your program). I'd even go so far as to venture that for any reasonably successful program, quite a lot of optimization time can be a net gain for the economy at large. If I ever am in a position to do it, I will mandate that executive demos will always be first done using a 10-25th percentile machine from our current target market. Only once it is shown to run reasonably on that, will the team be allowed to show what it can do on better hardware.
Sep 11 2009
prev sibling parent reply language_fan <foo bar.com.invalid> writes:
Fri, 11 Sep 2009 16:10:28 +0000, BCS thusly wrote:

 If I ever am in a position to do it, I will mandate that executive demos
 will always be first done using a 10-25th percentile machine from our
 current target market. Only once it is shown to run reasonably on that,
 will the team be allowed to show what it can do on better hardware.

I wonder how you can do that. E.g. if you are on the console game industry, the platforms and their capabilities are well known. No developer will want to write code for something prev gen. The lead coders and their superiors also have experience in optimizing the pre-releases and know how much can be improved each time. Agile development methods are used so the final result does not really come as a surprise. Often the timeframe of a final release is as low as 6 months, with one month iterations. There simply is not time to hand optimize every possible bit. Many have switched to c# from obj-c and c++, because the legacy languages just suck when they are in a hurry.
Sep 11 2009
next sibling parent BCS <none anon.com> writes:
Hello language_fan,

 Fri, 11 Sep 2009 16:10:28 +0000, BCS thusly wrote:
 
 If I ever am in a position to do it, I will mandate that executive
 demos will always be first done using a 10-25th percentile machine
 from our current target market. Only once it is shown to run
 reasonably on that, will the team be allowed to show what it can do
 on better hardware.
 

industry, the platforms and their capabilities are well known. No developer will want to write code for something prev gen.

First, I have zero interest in game development so that's not an issue for me.
 The lead
 coders and their superiors also have experience in optimizing the
 pre-releases and know how much can be improved each time. Agile
 development methods are used so the final result does not really come
 as a surprise.

OK so the lead knows that they can make things x times faster. Well then the demo on the 10-25th percentile machine must not be x times slower than what you need on ship day. Exactly the same as would be true if the demo were done on a 50th or 75th percentile machine.
 Often the timeframe of a final release is as low as 6
 months, with one month iterations. There simply is not time to hand
 optimize every possible bit. Many have switched to c# from obj-c and
 c++, because the legacy languages just suck when they are in a hurry.

As above, this is exactly the same regardless of what the demo is done on. This is the classic "fast cheap or well done, pick two". For anything that will ship, I'll always pick well done.
Sep 11 2009
prev sibling parent reply language_fan <foo bar.com.invalid> writes:
Fri, 11 Sep 2009 16:33:56 +0000, BCS thusly wrote:

 First, I have zero interest in game development so that's not an issue
 for me.

Game development is one of the largest users of systems programming languages.
 OK so the lead knows that they can make things x times faster. Well then
 the demo on the 10-25th percentile machine must not be x times slower
 than what you need on ship day. Exactly the same as would be true if the
 demo were done on a 50th or 75th percentile machine.

Well basically you could do that. Usually it does not work that way. The idea is to prioritize the features and remove the worst ones. It cannot be known beforehand which features are unnecessary, and there is a hard limit on how much can be removed. So either you can remove say 30-50% of features or do a complete redesign. But if you end up using only 50% of the potential resources of the platform, your game will usually suck (if the audience is technology oriented as it usually is).
 
 This is the classic "fast cheap or well done, pick two". For anything
 that will ship, I'll always pick well done.

That is ok if you are a hobby programmer, but in real world e.g. in the game industry the contracts pretty much dictate the schedules and if you spend too much time on the project, the producer will not offer any extra money. So if $1000..$1500 / month is ok for you, then fine.
Sep 11 2009
next sibling parent BCS <none anon.com> writes:
Hello language_fan,

 Fri, 11 Sep 2009 16:33:56 +0000, BCS thusly wrote:
 
 First, I have zero interest in game development so that's not an
 issue for me.
 

languages.

I would mandate the 10-25% test no mater what language is being used. The bulk of programming is done for Finance, Insurance and Real Estate (and is done in COBOL </yuck>) The most common programs out there are OSs and MS Office. As I said, I don't care about games.
 OK so the lead knows that they can make things x times faster. Well
 then the demo on the 10-25th percentile machine must not be x times
 slower than what you need on ship day. Exactly the same as would be
 true if the demo were done on a 50th or 75th percentile machine.
 

The idea is to prioritize the features and remove the worst ones.

well that's also a way to make it run faster.
 It
 cannot be known beforehand which features are unnecessary, and there
 is a hard limit on how much can be removed. So either you can remove
 say 30-50% of features

Clearly you can't cut core features, but you can make some eye candy features go away when there isn't enough power to run them.
 or do a complete redesign.

If a different design is practical and would be faster, you should have used it in the first place or should be planning on doing it at some point anyway (I have never seen a non trivial program that was fast enough that I didn't whish it was faster).
 But if you end up
 using only 50% of the potential resources of the platform, your game
 will usually suck (if the audience is technology oriented as it
 usually is).
 
 This is the classic "fast cheap or well done, pick two". For anything
 that will ship, I'll always pick well done.
 

the game industry the contracts pretty much dictate the schedules and if you spend too much time on the project, the producer will not offer any extra money. So if $1000..$1500 / month is ok for you, then fine.

I will grant that games can legitimately require top of the line hardware (scientific programs, and some things like photoshop can also) but most anything that runs on a desktop should be written so that people can run it with the hardware they have now, rather than have to buy new hardware
Sep 11 2009
prev sibling parent reply language_fan <foo bar.com.invalid> writes:
Fri, 11 Sep 2009 22:41:32 +0000, BCS thusly wrote:

 Hello language_fan,
 
 Fri, 11 Sep 2009 16:33:56 +0000, BCS thusly wrote:
 
 First, I have zero interest in game development so that's not an issue
 for me.
 

languages.

I would mandate the 10-25% test no mater what language is being used. The bulk of programming is done for Finance, Insurance and Real Estate (and is done in COBOL </yuck>) The most common programs out there are OSs and MS Office. As I said, I don't care about games.

I was talking about systems programming languages like C or D. From wikipedia "The term system programming language is also (and perhaps more widely) used to mean "a language for system programming": that is, a language designed for writing system software as distinct from application software. In contrast with application languages, such system programming languages typically offer more direct access to the physical hardware of the machine: an archetypical system programming language in this sense was BCPL. The distinction between languages for system programming and applications programming became blurred with widespread popularity of C." The various application domains you listed actually often do not use systems programming languages, at least the majority of their code does not. Things like database engines, drivers, operating systems, firmware, virtual machines (and games) on the other hand have no choice. For instance the code I have seen on the finance industry used languages Java (J2EE), Awk, Perl, and Javascript. What is a bit confusing is that you mentioned operating systems and MS Office. 99.9% of companies worldwide do not develop any code even as plugins to those. For example MS Office is a native executable only for business reasons. There is nothing preventing them from providing it as an applet or web service (like google does). Office suites are in no way performance limited these days. In fact I think parts of the competitor OpenOffice.org has been written in Java.
  
 OK so the lead knows that they can make things x times faster. Well
 then the demo on the 10-25th percentile machine must not be x times
 slower than what you need on ship day. Exactly the same as would be
 true if the demo were done on a 50th or 75th percentile machine.
 

The idea is to prioritize the features and remove the worst ones.

well that's also a way to make it run faster.
 It
 cannot be known beforehand which features are unnecessary, and there is
 a hard limit on how much can be removed. So either you can remove say
 30-50% of features

Clearly you can't cut core features, but you can make some eye candy features go away when there isn't enough power to run them.

Making business decisions is not that easy, especially if you have no idea of the application domain. There are several stakeholders and various contracts involved.
 
 or do a complete redesign.

If a different design is practical and would be faster, you should have used it in the first place or should be planning on doing it at some point anyway (I have never seen a non trivial program that was fast enough that I didn't whish it was faster).

Large parts of software projects worldwide fail. Redesigning for instance a single iteration is not that bad. You seem to favor the top-down waterfall model. Unfortunately the waterfall model usually fails. If you had studied software engineering lately, you would know that.
 But if you end up
 using only 50% of the potential resources of the platform, your game
 will usually suck (if the audience is technology oriented as it usually
 is).
 
 This is the classic "fast cheap or well done, pick two". For anything
 that will ship, I'll always pick well done.
 

game industry the contracts pretty much dictate the schedules and if you spend too much time on the project, the producer will not offer any extra money. So if $1000..$1500 / month is ok for you, then fine.

hardware (scientific programs, and some things like photoshop can also) but most anything that runs on a desktop should be written so that people can run it with the hardware they have now, rather than have to buy new hardware

Nowadays, as the piracy is hindering PC sales quite a lot, the focus is on console, mobile, and online games. The hardware specifications do not change that often, but it is still a bit hard to foretell what kind of stuff works. If the producer decides to want a split screen game mode 2 months before deadline, it is not clear at all if the final frame rate will be below acceptable level in some parts of the game.
Sep 12 2009
parent BCS <none anon.com> writes:
Hello language_fan,

 Fri, 11 Sep 2009 22:41:32 +0000, BCS thusly wrote:
 
 Hello language_fan,
 
 Game development is one of the largest users of systems programming
 languages.
 

The bulk of programming is done for Finance, Insurance and Real Estate (and is done in COBOL </yuck>) The most common programs out there are OSs and MS Office. As I said, I don't care about games.

wikipedia

I'm talking about systems programming languages AND any other language that is used.
 What is a bit confusing is that you mentioned operating systems and MS
 Office. 99.9% of companies worldwide do not develop any code even as
 plugins to those. For example MS Office is a native executable only
 for business reasons. There is nothing preventing them from providing
 it as an applet or web service (like google does). Office suites are
 in no way performance limited these days. In fact I think parts of the
 competitor OpenOffice.org has been written in Java.

My point is that games are NOT representative. In terms of lines of code written, Finance, Insurance and Real Estate dominate and in terms of lines of code executed, (after LAMPACK) MS Office, it's clones, Windows and Linux dominate. The only place games dominate is in the mind share some category of home users.
 It cannot be known beforehand which features are unnecessary, and there
 is a hard limit on how much can be removed. So either you can remove
 say 30-50% of features

Clearly you can't cut core features, but you can make some eye candy features go away when there isn't enough power to run them.


Easy? No. But that's what someone gets paid big money to do. Or are you saying that it's impossible?...
 especially if you have no idea of the application domain.

"I didn't do enough market research so I'm going to give the end user every thing they might want and then ask them to buy a bigger computer to run it because I'm to lazy to make the resulting mess fast."
 There are several stakeholders and various contracts involved.

"Our program manger is to lazy to get the stakeholders to give us a rational coherent spec." The business decisions here is that *I* WILL NOT force my costumers to buy a new computer every 1-3 years. And even if they don't need to buy a new computer, if I can make my code 1% faster for 1 minute of effort, I only need to save my user 100 minutes of time for it to be a net gain. I'm asserting, without proof, that there are vanishing few desktop applications out there that need anywhere near the computer power that is available now days (e.i. they should rarely have any perceivable wait time on a remotely modern system).
 or do a complete redesign.
 

have used it in the first place or should be planning on doing it at some point anyway (I have never seen a non trivial program that was fast enough that I didn't whish it was faster).

instance a single iteration is not that bad. You seem to favor the top-down waterfall model. Unfortunately the waterfall model usually fails. If you had studied software engineering lately, you would know that.

/Some/ sort of design is needed even in an agile model, and even if you don't bother with a detailed design, as you pointed out, redesigning/refactor should always be an option. Again, if a different faster design is practical, sooner or later you should use it.
 This is the classic "fast cheap or well done, pick two". For
 anything that will ship, I'll always pick well done.
 

the game industry the contracts pretty much dictate the schedules and if you spend too much time on the project, the producer will not offer any extra money. So if $1000..$1500 / month is ok for you, then fine.

hardware (scientific programs, and some things like photoshop can also) but most anything that runs on a desktop should be written so that people can run it with the hardware they have now, rather than have to buy new hardware


The above can be read as "Ok you might have a point about games" but...
 Nowadays, as the piracy is hindering PC sales quite a lot, the focus
 is on console, mobile, and online games.

Could you quit going back to games already?! I DON'T CARE A WIT ABOUT GAMES!!!! If an argument doesn't apply to non-games I don't care.
Sep 15 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Fri, 11 Sep 2009 09:34:54 +0200, Don thusly wrote:

 dsimcha wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 In general though, I find the "programmer time is more expensive than
 hardware" line to largely be a cop-out.

Fair enough, but can you elaborate on this? Of course hardware is getting cheaper relative to programming time. This is obvious to anyone who doesn't live under a rock. My previous post was pointing out how this is relevant in case that was less obvious.

Probably because you need to consider maintenance time. Poor quality ends up costing you in the long term. Good quality code gets reused.

Another point related to maintenance costs is the choice of language. Many smaller companies choose "easier" languages like php, visual basic, or python for their applications because they outsource library writing and it is much cheaper and easier to hire new workforce for business logic when the existing codebase does not use any complex idioms or language constructs. Some indian schoolboy can write e.g. php pages $1-2/ h, a hard-core C++/Haskell professional easily costs $500/h.
Sep 11 2009
prev sibling parent language_fan <foo bar.com.invalid> writes:
Fri, 11 Sep 2009 16:16:07 -0400, Justin Johansson thusly wrote:

 Another point related to maintenance costs is the choice of language.
 Many smaller companies choose "easier" languages like php, visual
 basic, or python for their applications because they outsource
 library writing and it is much cheaper and easier to hire new
 workforce for business logic when the existing codebase does not use
 any complex idioms or language constructs. Some indian schoolboy can
 write e.g. php pages $1-2/ h, a hard-core C++/Haskell professional
 easily costs $500/h.

Haven't heard of many $500/h gigs. Andrei

I have. Haven't you every been to see a lawyer :-) Seriously, the OP must have meant $500/day.

Unfortunately no. I live in the ECU area and even my consulting costs are on average about 150..200 eur/h + travel expenses. A normal senior level developer on any field of computer engineering gets $500/day.
Sep 12 2009