9 ms·

I have happily traded working in a nice language with slow iteration times to working in a lousy language with very, very fast turnaround. My favorite extreme

by kabdib 9y ago

I have happily traded working in a nice language with slow iteration times to working in a lousy language with very, very fast turnaround. My favorite extreme example was the time I used a super fast 6502 assembler environment that would do the "change a line of code and get the target running" cycle in a couple of seconds. This kind of interaction is magical. You're still writing kind of crappy assembly language, but it almost doesn't matter. Things just flow. On the other extreme: A large component of me deciding to quit a job was the fact that a build of the product took four hours. And the build was typically broken. So: Arrive in the morning, sync, wait all morning for the build to fail. Do another cycle after lunch: fail. Go home, repeat for weeks. (Add to this: Managers who refused to buy decent development machines, people who kept checking in busted code and making things worse, and a crushing schedule. Who needs that?) These days I'm do a lot of C++, and some PHP. The C++ projects take a few minutes to build, which isn't great, but it's survivable. The PHP "builds" as fast as I can refresh a browser page. And as much as it pains me, on most days, when I grit my teeth and get honest about it, I'm more productive in PHP. And I despise PHP. I learned LISP early on in my career; wrote a few LISP interpreters, goggled at the majesty of LISP machines, read all that I could. But I've never shipped a significant project in LISP, nor am I likely to. And the Newton actually flipped from a LISP (well, OOPy-Scheme) implementation language to C++ in order to ship. I'm wondering if there is some law of human nature at work: You can have elegance and comfort or you can have a product. I sure hope I'm wrong.

ece 9y ago
TDD can help with this. I more often than not, will write a unit test or functional test first, then work on the code for that test where I'm just running that one test until it succeeds. After I have individual parts working, I will integrate everything, which again will just be another integration test run from the IDE. I realize this isn't always possible, and is probably easier to do in a managed language, but you can cut down on iteration times by mostly forcing the IDE to do incremental compiles. You can work in real-time on code that might take tens of minutes for a full build. TDD is fun.
- jnbiche 9y ago
  Despite being downvoted, this assertion about TDD is true. It can provide a very interactive experience when programming, even with languages with little natural interactivity. But you have to know how to set up the tests.
  - breatheoften 9y ago
    I'm enjoying wallabyjs with jest and vscode. It's quite fun having feedback from test execution always available in the IDE. I don't have a long build step for my codebase (compiling typescript just takes a few seconds and incremental is instant) -- but I do avoid lengthy deployment cycles -- deploying code to aws lambda takes quite awhile.
  - ece 9y ago
    A good IDE will go a long way here. Any of the IntelliJ IDEs are interactive in almost any aspect of technical coding. Setting up and running a test is a left click, if you've written the function and annotated it in Scala. I've been trying to use Atom for some embedded coding, and some of the plugins for it are pretty good, but not completely free. MS VS is up there too, but I haven't used it in a long time. Off course, writing testable code using OO almost requires dependency injection IMO. With FP, it's almost trivial.
- tcbawo 9y ago
  have you ever tried BDD (behavior driven development)? one of the interesting aspects of this is being able to develop the test implementation in a different (possible more expressive) language
  - ece 9y ago
    For web development, yes. Once you know pretty much what you want, and have a good idea of how you're going to go about implementing it, it can be fast. If you're new, don't know what you want, and are starting out on a framework, it can be an impassable chasm. If you're just experimenting, it's also a bit too much. Starting with a simple unit test or spec (what I meant by functional testing, though this can be BDD too) can be easier to start with and change as you figure out what you want. Even with specs, or a BDD framework like you said, no need to bring in a whole new DSL unless you need it IMHO, others may disagree.
dmytroi 9y ago
One of the reasons why I switched from C++ to C professionally (I do C for living) was build times: previously kind of big casual game took 5-10 minutes to compile and around 10-20 sec incremental build, and now my C project takes 5 second to compile from scratch and around 1 second to do incremental changes. Another reason being that I don't need to waste time discussing and arguing which OOP patterns to use - in C it more or less fixed how you write code. Of course one can go extra mile and reinvent VTable and Dependency Injection, but it feels all foreign to C. So maybe give C a try, it's amazingly fast to compile and link, yet you feel almost at home after C++.
- im3w1l 9y ago
  How do you cope with the lack of template containers? That's the big thing I miss in C.
  - dmytroi 9y ago
    Great question! To make things even more annoying - C doesn't have namespaces. So people are forced to write long names like "my_struct_hash_map_t" everywhere, which makes all modern C code look like wall of text (compare too older style code "mshm_t*a = hmalloc()"). To answer honestly - I'm asking myself very pragmatic question: "do I really need a generic code?" much more often compare to C++. In game development C++ templates were used mostly for math libraries (2d/3d/4d vectors, matrices, etc) and containers (hashmap, lists, etc). If we look closely on math libraries we can make a compromise "just float is enough", and if we make such compromise then everything is simple - one don't need templates for math lib anymore, I'm currently using "gb_math.h" [1] and it works pretty good. Containers on the other hand are more challenging, the key here is to understand "can I make this work with linear (maybe static) array?" - and in most cases yes, then you don't need any containers because just arrays will do. If algorithm specific do require a hashmap or list, well, gonna use what we have: macro! It looks weird, and it is weird, but something like khash.h [2] works fine in production. In reality what it means for me is that I need to spend time making decisions about containers, which is good for game development, as what makes games fun doesn't have any connection to templates. But it also bad for casual non-game related code. I find it much faster to just "hey load this json, do some processing, and save json back" do that in Python than trying to do in C just for sake of C. Ideally namespaces/templates and operator overloading in C would solve all this struggles, but then where C ends and C++ starts? - [1] https://github.com/gingerBill/gb/blob/master/gb_math.h https://github.com/gingerBill/gb/blob/master/gb_math.h - [2] https://github.com/attractivechaos/klib/blob/master/khash.h https://github.com/attractivechaos/klib/blob/master/khash.h
jasode 9y ago
> to working in a lousy language with very, very fast turnaround. [...] The PHP "builds" as fast as I can refresh a browser page. This observation ("workflow") was one of the 3 bullet points outlined by Keith Adams' 2013 presentation "Taking PHP Seriously".[1][2] (KA's presentation was partially a response to 2012 "PHP a Fractal of Bad Design".[3]) Basically, the horrendous inconsistencies and flaws outlined in "PHP Fractal Bad" can be true ... but simultaneously be overshadowed by "workflow" benefits. [1] starting with slide #14 of "Adams-TakingPHPSeriously.pdf" : https://github.com/strangeloop/StrangeLoop2013/tree/master/slides/sessions https://github.com/strangeloop/StrangeLoop2013/tree/master/s... [2] 4 previous HN threads: https://hn.algolia.com/?query=php%20seriously&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=php%20seriously&sort=byPopular... [3] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
- SomeCallMeTim 9y ago
  I have been using TypeScript. The TypeScript compiler gives me roughly 1-2 second builds, even on a large project that (it can watch code and build incrementally). So I get the benefits of static types, plus the benefits of fast iteration, PLUS the benefits of a fully dynamic language for when I want to accomplish something quickly. It's a full win-win-win. Throw in linting to avoid the legacy JavaScript crap and it's pretty awesome.
bambax 9y ago
> The PHP "builds" as fast as I can refresh a browser page JavaScript is just as fast, or faster. That's probably an important reason why it's "eating the world".
- konschubert 9y ago
  So is python, which is a much nicer language.
  - thesmallestcat 9y ago
    You don't know what you're talking about. Python process needs to be bounced, or has to watch files and bounce itself on change. The PHP runtime is designed to read the file on each request. You have to go out of your way to require restarts (it is an optimization). PHP has the only mainstream runtime AFAIK that is designed this way (+ the model is stateless, so each refresh really is one). I'm not a PHP fan but it bothers me that people don't acknowledge some of its important, unique features and are content to rag on its inadequacies. It bothers me because we're probably ten years from people forgetting what PHP was, and creating a new, worse PHP (!).
    - jaipilot747 9y ago
      This message would have been just as effective without the opening accusation.
      - thesmallestcat 9y ago
        Sorry, you're right, I was annoyed by the "hurr durr Python" tone.
        35bge57dtjku 9y ago
        It didn't even have that tone...
coldtea 9y ago
While I agree with the first part (immediate feedback is essential), I'm not sure about the connection with LISP in the end. Doesn't LISP offer the same "fast feedback" cycle that e.g. PHP or whatever does? And even faster than C++?
- kabdib 9y ago
  It's kind of my point: LISP does (mostly) provide instant feedback, but it's not used much in the real world (every big LISP success I've heard of wound up either being translated into a shlub language, or resulted in the teams using it having a really hard time hiring people and scaling).
  - didibus 9y ago
    Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less familiar people are, the less likely they can have good teachers and teaching material about it, etc.
    - SomeCallMeTim 9y ago
      I spent months working on a Lisp project in college. I pretty much hated it. Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of mastery, and I've learned more than a dozen to a high level of mastery. After a while you have to stop blaming the people and instead just admit that Lisp isn't as awesome-for-all-purposes as some famous people seem to think it is.
      - coldtea 9y ago

by kabdib 9y ago

ece 9y ago

TDD can help with this. I more often than not, will write a unit test or functional test first, then work on the code for that test where I'm just running that one test until it succeeds. After I have individual parts working, I will integrate everything, which again will just be another integration test run from the IDE. I realize this isn't always possible, and is probably easier to do in a managed language, but you can cut down on iteration times by mostly forcing the IDE to do incremental compiles. You can work in real-time on code that might take tens of minutes for a full build. TDD is fun.

jnbiche 9y ago
Despite being downvoted, this assertion about TDD is true. It can provide a very interactive experience when programming, even with languages with little natural interactivity. But you have to know how to set up the tests.
- breatheoften 9y ago
  I'm enjoying wallabyjs with jest and vscode. It's quite fun having feedback from test execution always available in the IDE. I don't have a long build step for my codebase (compiling typescript just takes a few seconds and incremental is instant) -- but I do avoid lengthy deployment cycles -- deploying code to aws lambda takes quite awhile.
- ece 9y ago
  A good IDE will go a long way here. Any of the IntelliJ IDEs are interactive in almost any aspect of technical coding. Setting up and running a test is a left click, if you've written the function and annotated it in Scala. I've been trying to use Atom for some embedded coding, and some of the plugins for it are pretty good, but not completely free. MS VS is up there too, but I haven't used it in a long time. Off course, writing testable code using OO almost requires dependency injection IMO. With FP, it's almost trivial.
tcbawo 9y ago
have you ever tried BDD (behavior driven development)? one of the interesting aspects of this is being able to develop the test implementation in a different (possible more expressive) language
- ece 9y ago
  For web development, yes. Once you know pretty much what you want, and have a good idea of how you're going to go about implementing it, it can be fast. If you're new, don't know what you want, and are starting out on a framework, it can be an impassable chasm. If you're just experimenting, it's also a bit too much. Starting with a simple unit test or spec (what I meant by functional testing, though this can be BDD too) can be easier to start with and change as you figure out what you want. Even with specs, or a BDD framework like you said, no need to bring in a whole new DSL unless you need it IMHO, others may disagree.

dmytroi 9y ago

One of the reasons why I switched from C++ to C professionally (I do C for living) was build times: previously kind of big casual game took 5-10 minutes to compile and around 10-20 sec incremental build, and now my C project takes 5 second to compile from scratch and around 1 second to do incremental changes. Another reason being that I don't need to waste time discussing and arguing which OOP patterns to use - in C it more or less fixed how you write code. Of course one can go extra mile and reinvent VTable and Dependency Injection, but it feels all foreign to C. So maybe give C a try, it's amazingly fast to compile and link, yet you feel almost at home after C++.

im3w1l 9y ago
How do you cope with the lack of template containers? That's the big thing I miss in C.
- dmytroi 9y ago
  Great question! To make things even more annoying - C doesn't have namespaces. So people are forced to write long names like "my_struct_hash_map_t" everywhere, which makes all modern C code look like wall of text (compare too older style code "mshm_t*a = hmalloc()"). To answer honestly - I'm asking myself very pragmatic question: "do I really need a generic code?" much more often compare to C++. In game development C++ templates were used mostly for math libraries (2d/3d/4d vectors, matrices, etc) and containers (hashmap, lists, etc). If we look closely on math libraries we can make a compromise "just float is enough", and if we make such compromise then everything is simple - one don't need templates for math lib anymore, I'm currently using "gb_math.h" [1] and it works pretty good. Containers on the other hand are more challenging, the key here is to understand "can I make this work with linear (maybe static) array?" - and in most cases yes, then you don't need any containers because just arrays will do. If algorithm specific do require a hashmap or list, well, gonna use what we have: macro! It looks weird, and it is weird, but something like khash.h [2] works fine in production. In reality what it means for me is that I need to spend time making decisions about containers, which is good for game development, as what makes games fun doesn't have any connection to templates. But it also bad for casual non-game related code. I find it much faster to just "hey load this json, do some processing, and save json back" do that in Python than trying to do in C just for sake of C. Ideally namespaces/templates and operator overloading in C would solve all this struggles, but then where C ends and C++ starts? - [1] https://github.com/gingerBill/gb/blob/master/gb_math.h https://github.com/gingerBill/gb/blob/master/gb_math.h - [2] https://github.com/attractivechaos/klib/blob/master/khash.h https://github.com/attractivechaos/klib/blob/master/khash.h

jasode 9y ago

> to working in a lousy language with very, very fast turnaround. [...] The PHP "builds" as fast as I can refresh a browser page. This observation ("workflow") was one of the 3 bullet points outlined by Keith Adams' 2013 presentation "Taking PHP Seriously".[1][2] (KA's presentation was partially a response to 2012 "PHP a Fractal of Bad Design".[3]) Basically, the horrendous inconsistencies and flaws outlined in "PHP Fractal Bad" can be true ... but simultaneously be overshadowed by "workflow" benefits. [1] starting with slide #14 of "Adams-TakingPHPSeriously.pdf" : https://github.com/strangeloop/StrangeLoop2013/tree/master/slides/sessions https://github.com/strangeloop/StrangeLoop2013/tree/master/s... [2] 4 previous HN threads: https://hn.algolia.com/?query=php%20seriously&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=php%20seriously&sort=byPopular... [3] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

SomeCallMeTim 9y ago
I have been using TypeScript. The TypeScript compiler gives me roughly 1-2 second builds, even on a large project that (it can watch code and build incrementally). So I get the benefits of static types, plus the benefits of fast iteration, PLUS the benefits of a fully dynamic language for when I want to accomplish something quickly. It's a full win-win-win. Throw in linting to avoid the legacy JavaScript crap and it's pretty awesome.

bambax 9y ago

> The PHP "builds" as fast as I can refresh a browser page JavaScript is just as fast, or faster. That's probably an important reason why it's "eating the world".

konschubert 9y ago
So is python, which is a much nicer language.
- thesmallestcat 9y ago
  You don't know what you're talking about. Python process needs to be bounced, or has to watch files and bounce itself on change. The PHP runtime is designed to read the file on each request. You have to go out of your way to require restarts (it is an optimization). PHP has the only mainstream runtime AFAIK that is designed this way (+ the model is stateless, so each refresh really is one). I'm not a PHP fan but it bothers me that people don't acknowledge some of its important, unique features and are content to rag on its inadequacies. It bothers me because we're probably ten years from people forgetting what PHP was, and creating a new, worse PHP (!).
  - jaipilot747 9y ago
    This message would have been just as effective without the opening accusation.
    - thesmallestcat 9y ago
      Sorry, you're right, I was annoyed by the "hurr durr Python" tone.
      - 35bge57dtjku 9y ago
        It didn't even have that tone...

coldtea 9y ago

While I agree with the first part (immediate feedback is essential), I'm not sure about the connection with LISP in the end. Doesn't LISP offer the same "fast feedback" cycle that e.g. PHP or whatever does? And even faster than C++?

kabdib 9y ago
It's kind of my point: LISP does (mostly) provide instant feedback, but it's not used much in the real world (every big LISP success I've heard of wound up either being translated into a shlub language, or resulted in the teams using it having a really hard time hiring people and scaling).
- didibus 9y ago
  Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less familiar people are, the less likely they can have good teachers and teaching material about it, etc.
  - SomeCallMeTim 9y ago
    I spent months working on a Lisp project in college. I pretty much hated it. Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of mastery, and I've learned more than a dozen to a high level of mastery. After a while you have to stop blaming the people and instead just admit that Lisp isn't as awesome-for-all-purposes as some famous people seem to think it is.
    - coldtea 9y ago