5 ms·

Honestly, just about anything is going to be faster, productivity-wise, than C++. When you stop having to think about how you're going to structure your inheri

Honestly, just about anything is going to be faster, productivity-wise, than C++. When you stop having to think about how you're going to structure your inheritance and classes, you--shockingly--get things done. But more metaprogramming is not the answer. And I've used Scheme since 2002 or so. I'm implemented Scheme interpreters and compilers. But I'm no longer a cheerleader for macros and call/cc or Scheme (or Lisp, for that matter). You know what gets things done and makes things easy to maintain? Boring ass code. IF statements. FOR loops. I mostly use Perl today. It doesn't get in the way. But getting things done is not trendy. That's where we are today.

andrewchambers 12y ago
"You know what gets things done and makes things easy to maintain? Boring ass code. IF statements. FOR loops." I think you are channeling some of the Go philosophy there :).
- robmccoll 12y ago
  Or C philosophy perhaps?
  - elmin 12y ago
    The C philosophy is: an easier alternative to writing assembly.
- Dewie 12y ago
  "Go philosophy" apparently being an absolutist and unwavering belief in One True Way To Actually Get Stuff Done. It's surprising that a philosophy that tries to promote simplicity also manages to come across as so elitist at the same time.
  - axaxs 12y ago
    If there were multiple accepted styles, the code wouldn't be as boring. But it is, and to some of us, that's a good thing.
    - Dewie 12y ago
      Who's talking about code style? Some Go users like to talk about Go as if anyone who doesn't like it just dosn't "get it", or that they obviously don't appreciate Getting Things Done.
nine_k 12y ago
You know what's the problem with boring code? It's boring. This means its information content is low, and its abstraction level is low. This means that you need more of it to express an algorithm. When you have a lot of wordy, boring code to maintain, you have to make coordinated changes in more similarly boring places. A human's brain can only keep that many lines of context. So it becomes easier to make a mistake. I understand that abstraction astronautics can leave you with puzzling, convoluted, hard-to-maintain code full of leaky unintuitive abstractions. This problem is not unique to Lisp macros; languages like C++ and even Java are known to be widely used by perpetrators of the above-mentioned atrocities. What makes code easier to maintain is clear separation of concerns and low impedance between code's abstractions and the subject area. This is, again, attainable in a number of languages (though expressive power and minimalism help make it even nicer), given the right mindset and skills. I suppose John Carmack possesses both.
- mrits 12y ago
  I recently watch a colleague write an elaborate system to parse a few different CSV feeds. There are a dozen different interfaces and mixed in with all the lovely Java design patterns. I'm beginning to use a phrase that I'd rather deal with poorly written code than well planned architecture. Obviously by well planned architecture I'm referring to overly architected solutions.
  - nine_k 12y ago
    A well-planned architecture is often the smallest thing that works correctly. A well-architected car is unlikely to have 37 wheels (though a poorly-built one might). You know, the ideal device is that which is not even there, but its function gets executed. This ideal is rarely attainable, but it's something to crave for.
    - therealdrag0 12y ago
      Very much this. Refactoring simple code to handle more complicated situation as it develops is so much better than pre-engineering for possibilities.
eru 12y ago
Racket is quite a lot more than call/cc and macros. By the way, FOR loops invite off-by-one errors and worse. Use a combinator like map, or filter or foldr etc, to keep things boring.
- Sanddancer 12y ago
  For loops in perl have two styles. The first is the c-style loop, the other is a map. One often uses the latter style a lot more often.
  - pyre 12y ago
    That, and Perl has an actual `map` function too: map { $_ + 1 } (@list);
    - huehue 12y ago
      Sometimes Perl can be a beauty: sub sum_of_squared_pairs { reduce { $a + $b } map { $_ * $_ } grep { $_ % 2 == 0 } @_ } sub schwartzian_transform { map { $_->[0] } sort { $a->[1] <=> $b->[1] } # use numeric comparison map { [$_, length $_] } # calculate the length of the string @_ }
    - eru 12y ago
      Yes, but _ has dynamic scope (I believe). That's very dangerous in general.
- minikomi 12y ago
  There are also the extremely "boring" & practical list comprehensions / iterators within racket itself: http://docs.racket-lang.org/reference/for.html http://docs.racket-lang.org/reference/for.html eg. fizzbuzz using for, match: -> (for ([i (range 1 16)]) (match (list (modulo i 3) (modulo i 5)) [(list 0 0) (displayln "fizzbuzz")] [(list 0 _) (displayln "fizz")] [(list _ 0) (displayln "buzz")] [_ (displayln i)])) 1 2 fizz 4 buzz fizz 7 8 fizz buzz 11 fizz 13 14 fizzbuzz
gaius 12y ago
Honestly, just about anything is going to be faster, productivity-wise, than C++. I don't think that's been true for a while. Boost went a long way towards making C++ much more productive, and now that's gone even further with C++11 and 14.
- MaulingMonkey 12y ago
  Compile times are still terrible, there's still a terribly high number of causes for undefined behavior that will burn through your time in debugging sessions, and there's terribly far to go still before it's feature list catches up to "just about anything" (albeit a slightly smaller set this time around.) Things are improving in C++-land, but I'd still place it near last.
mseepgood 12y ago
Carmack seems to go through his FP phase. A phase that many programmers go through in their younger years (Carmack must have missed it, because he was occupied with Keen, Wolfenstein, Doom and Quake at that time), when they read SICP, learn Scheme, ML, etc. before the novelty wears off and they come back to plain old imperative, mutable programming.
- moomin 12y ago
  What you're not seeing is the successes who acheive escape velocity. They don't come back, ever.
MrBuddyCasino 12y ago
Ha. JWZ of XEmacs and Lucid fame nowadays uses Perl for the little tools he writes. I hate to admit it, but I think you're right.
- krylon 12y ago
  I came back to Perl about 18 months ago, after working as a sysadmin for a couple of months and being fed up with Python's unicode handling (Python 2.x, I haven't given Python 3.x a try, yet). I do not think Perl is a pretty language, but I have come to appreciate how useful it is. If all you want is a smallish application (roughly, less than 1 KLOC), especially if you're only going to use it once or maybe a handful of times, no other language I have met can keep up. And for the kind of problem I typically use Perl for - reading, say, a CSV file or an Excel spreadsheet, filtering the data according to some criterion, fetching and adding data from an external source, say, an LDAP directory or a relational database, then inserting the result into a database or emitting another CSV file - it is also surprisingly hard to beat Perl's runtime performance, especially its regex engine. I'm not saying it can't be done, but for a program you're essentially throwing away after a week or so, it's usually not worth the hassle.
venomsnake 12y ago
> Honestly, just about anything is going to be faster, productivity-wise, than C++. I can only assume you have not seen 300+ deep stack traces in lasagna java programs. Or GWT.

andrewchambers 12y ago

"You know what gets things done and makes things easy to maintain? Boring ass code. IF statements. FOR loops." I think you are channeling some of the Go philosophy there :).

robmccoll 12y ago
Or C philosophy perhaps?
- elmin 12y ago
  The C philosophy is: an easier alternative to writing assembly.
Dewie 12y ago
"Go philosophy" apparently being an absolutist and unwavering belief in One True Way To Actually Get Stuff Done. It's surprising that a philosophy that tries to promote simplicity also manages to come across as so elitist at the same time.
- axaxs 12y ago
  If there were multiple accepted styles, the code wouldn't be as boring. But it is, and to some of us, that's a good thing.
  - Dewie 12y ago
    Who's talking about code style? Some Go users like to talk about Go as if anyone who doesn't like it just dosn't "get it", or that they obviously don't appreciate Getting Things Done.

nine_k 12y ago

You know what's the problem with boring code? It's boring. This means its information content is low, and its abstraction level is low. This means that you need more of it to express an algorithm. When you have a lot of wordy, boring code to maintain, you have to make coordinated changes in more similarly boring places. A human's brain can only keep that many lines of context. So it becomes easier to make a mistake. I understand that abstraction astronautics can leave you with puzzling, convoluted, hard-to-maintain code full of leaky unintuitive abstractions. This problem is not unique to Lisp macros; languages like C++ and even Java are known to be widely used by perpetrators of the above-mentioned atrocities. What makes code easier to maintain is clear separation of concerns and low impedance between code's abstractions and the subject area. This is, again, attainable in a number of languages (though expressive power and minimalism help make it even nicer), given the right mindset and skills. I suppose John Carmack possesses both.

mrits 12y ago
I recently watch a colleague write an elaborate system to parse a few different CSV feeds. There are a dozen different interfaces and mixed in with all the lovely Java design patterns. I'm beginning to use a phrase that I'd rather deal with poorly written code than well planned architecture. Obviously by well planned architecture I'm referring to overly architected solutions.
- nine_k 12y ago
  A well-planned architecture is often the smallest thing that works correctly. A well-architected car is unlikely to have 37 wheels (though a poorly-built one might). You know, the ideal device is that which is not even there, but its function gets executed. This ideal is rarely attainable, but it's something to crave for.
  - therealdrag0 12y ago
    Very much this. Refactoring simple code to handle more complicated situation as it develops is so much better than pre-engineering for possibilities.

eru 12y ago

Racket is quite a lot more than call/cc and macros. By the way, FOR loops invite off-by-one errors and worse. Use a combinator like map, or filter or foldr etc, to keep things boring.

Sanddancer 12y ago
For loops in perl have two styles. The first is the c-style loop, the other is a map. One often uses the latter style a lot more often.
- pyre 12y ago
  That, and Perl has an actual `map` function too: map { $_ + 1 } (@list);
  - huehue 12y ago
    Sometimes Perl can be a beauty: sub sum_of_squared_pairs { reduce { $a + $b } map { $_ * $_ } grep { $_ % 2 == 0 } @_ } sub schwartzian_transform { map { $_->[0] } sort { $a->[1] <=> $b->[1] } # use numeric comparison map { [$_, length $_] } # calculate the length of the string @_ }
  - eru 12y ago
    Yes, but _ has dynamic scope (I believe). That's very dangerous in general.
minikomi 12y ago
There are also the extremely "boring" & practical list comprehensions / iterators within racket itself: http://docs.racket-lang.org/reference/for.html http://docs.racket-lang.org/reference/for.html eg. fizzbuzz using for, match: -> (for ([i (range 1 16)]) (match (list (modulo i 3) (modulo i 5)) [(list 0 0) (displayln "fizzbuzz")] [(list 0 _) (displayln "fizz")] [(list _ 0) (displayln "buzz")] [_ (displayln i)])) 1 2 fizz 4 buzz fizz 7 8 fizz buzz 11 fizz 13 14 fizzbuzz

gaius 12y ago

Honestly, just about anything is going to be faster, productivity-wise, than C++. I don't think that's been true for a while. Boost went a long way towards making C++ much more productive, and now that's gone even further with C++11 and 14.

MaulingMonkey 12y ago
Compile times are still terrible, there's still a terribly high number of causes for undefined behavior that will burn through your time in debugging sessions, and there's terribly far to go still before it's feature list catches up to "just about anything" (albeit a slightly smaller set this time around.) Things are improving in C++-land, but I'd still place it near last.

mseepgood 12y ago

Carmack seems to go through his FP phase. A phase that many programmers go through in their younger years (Carmack must have missed it, because he was occupied with Keen, Wolfenstein, Doom and Quake at that time), when they read SICP, learn Scheme, ML, etc. before the novelty wears off and they come back to plain old imperative, mutable programming.

moomin 12y ago
What you're not seeing is the successes who acheive escape velocity. They don't come back, ever.

MrBuddyCasino 12y ago

Ha. JWZ of XEmacs and Lucid fame nowadays uses Perl for the little tools he writes. I hate to admit it, but I think you're right.

krylon 12y ago
I came back to Perl about 18 months ago, after working as a sysadmin for a couple of months and being fed up with Python's unicode handling (Python 2.x, I haven't given Python 3.x a try, yet). I do not think Perl is a pretty language, but I have come to appreciate how useful it is. If all you want is a smallish application (roughly, less than 1 KLOC), especially if you're only going to use it once or maybe a handful of times, no other language I have met can keep up. And for the kind of problem I typically use Perl for - reading, say, a CSV file or an Excel spreadsheet, filtering the data according to some criterion, fetching and adding data from an external source, say, an LDAP directory or a relational database, then inserting the result into a database or emitting another CSV file - it is also surprisingly hard to beat Perl's runtime performance, especially its regex engine. I'm not saying it can't be done, but for a program you're essentially throwing away after a week or so, it's usually not worth the hassle.

venomsnake 12y ago

> Honestly, just about anything is going to be faster, productivity-wise, than C++. I can only assume you have not seen 300+ deep stack traces in lasagna java programs. Or GWT.