3 ms·

On living on free in Perl: I consider Perl, Python, and Ruby to be a part of the broad category of dynamicly typed, OO, interpreted languages. They are all diff

On living on free in Perl: I consider Perl, Python, and Ruby to be a part of the broad category of dynamicly typed, OO, interpreted languages. They are all different, but do have a very similar basic concept. In my experience, for writing scalable code there is nothing better than a Python/Perl/Ruby developer who can and does also write C. When the programmer can make a mental translation from their P/P/R to C, they have a much better chance of writing fast code that scales well. This IMO is a killer combination of skills: you write fast code because you know how to avoid expensive operations, and you write code fast because you don't have to declare every struct and accessor method as you would in C. Then again, there is fast and scalable code, and there is actually shipping. Just because the code is very well written, counting every implied malloc() and memset(), does not mean it's worth anything if it's just sitting on your harddrive. Write code in whatever you are good at, and ship.

Cyther606 12y ago
Sums up the appeal of Nim [1], which recently benchmarked favorably to C++ [2]. import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive [1] https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers [2] https://www.reddit.com/r/programming/comments/2pvf68/armv7_vs_x8664_pathfinding_benchmark_of_c_d_go/cn0fkn1 https://www.reddit.com/r/programming/comments/2pvf68/armv7_v...
- codygman 12y ago
  Nim seems to be what I was wishing for Go to be. I'm pretty deep in Haskell right now, but Nim is definitely on my short list. Of interest is that it is homoiconic IIRC and not a lisp, has very good performance, and seems to have the pythonesque "one way to do it" mantra I believe.
vertex-four 12y ago
> Write code in whatever you are good at, and ship. Provided that you're not writing operating system code, or crypto code, or code with an inherently large attack surface (web browsers etc), or code which outright needs to be performant or it's useless (databases etc), or code which manages physical processes or lives, or code which deals with sensitive information (such as identifying details of real people). If it can cost someone's job, or leak someone's identity attached to some data, or worse - lose a human life - if it breaks, writing code in "whatever you're good at" isn't good enough.
- IgorPartola 12y ago
  Well, I'd rather see a really well written crypto lib in C, than a half finished one in Haskell, but yes I see your point. My main thing is that "genius has its limits" and all that: you can make mistakes in any language and it's not your choice of language that automatically determines if you are going to write crappy code. If you can't write a piece of code in Python that won't kill a person, I don't really trust you to write it in Rust either.
  - the_why_of_y 12y ago
    Actually I wouldn't want to see a crypto library in Haskell - crypto is quite special in that there is a requirement of deterministic timing, to prevent leaking secrets via timing attacks, which is rather impossible to guarantee in a high-level language, especially with a "smart" compiler like GHC that may optimize in non-obvious ways. Hence it could actually be most secure to implement cryptographic primitives in assembler, however counter-intuitive that may sound. (Also, how do you erase or overwrite secrets from memory after use in a purely functional language?)
    - tome 12y ago
      > (Also, how do you erase or overwrite secrets from memory after use in a purely functional language?) Your other concern is valid, but this is easy: Haskell has mutable arrays.

Cyther606 12y ago

Sums up the appeal of Nim [1], which recently benchmarked favorably to C++ [2]. import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive [1] https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers [2] https://www.reddit.com/r/programming/comments/2pvf68/armv7_vs_x8664_pathfinding_benchmark_of_c_d_go/cn0fkn1 https://www.reddit.com/r/programming/comments/2pvf68/armv7_v...

codygman 12y ago
Nim seems to be what I was wishing for Go to be. I'm pretty deep in Haskell right now, but Nim is definitely on my short list. Of interest is that it is homoiconic IIRC and not a lisp, has very good performance, and seems to have the pythonesque "one way to do it" mantra I believe.

vertex-four 12y ago

> Write code in whatever you are good at, and ship. Provided that you're not writing operating system code, or crypto code, or code with an inherently large attack surface (web browsers etc), or code which outright needs to be performant or it's useless (databases etc), or code which manages physical processes or lives, or code which deals with sensitive information (such as identifying details of real people). If it can cost someone's job, or leak someone's identity attached to some data, or worse - lose a human life - if it breaks, writing code in "whatever you're good at" isn't good enough.

IgorPartola 12y ago
Well, I'd rather see a really well written crypto lib in C, than a half finished one in Haskell, but yes I see your point. My main thing is that "genius has its limits" and all that: you can make mistakes in any language and it's not your choice of language that automatically determines if you are going to write crappy code. If you can't write a piece of code in Python that won't kill a person, I don't really trust you to write it in Rust either.
- the_why_of_y 12y ago
  Actually I wouldn't want to see a crypto library in Haskell - crypto is quite special in that there is a requirement of deterministic timing, to prevent leaking secrets via timing attacks, which is rather impossible to guarantee in a high-level language, especially with a "smart" compiler like GHC that may optimize in non-obvious ways. Hence it could actually be most secure to implement cryptographic primitives in assembler, however counter-intuitive that may sound. (Also, how do you erase or overwrite secrets from memory after use in a purely functional language?)
  - tome 12y ago
    > (Also, how do you erase or overwrite secrets from memory after use in a purely functional language?) Your other concern is valid, but this is easy: Haskell has mutable arrays.