Software Development at 1 Hz • Hacker News Board

Re: Software Development at 1 Hz

#101

Post by lmm » Mon, Sep 26, 2016, 12:03 PM UTC

userbinator wrote: post #59

ctdonath wrote: post #17

This is why interview code tests are... badly misguided. Most "fizzbuzz" screening is grossly artificial, denying one the feedback loops which are a critical element of productivity, and without which one is relegated to spending time manual checking what automation does almost instantly. I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think…

I would argue that if you can't write a correct FizzBuzz without needing to compile and run it, or even worse, an IDE to hold your hand, you don't actually understand what's happening and are just leaning on a crutch. I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think thru a myriad of special cases. The peril of that sort of workflow is th…

All tools are crutches. I mean a good carpenter probably should be able to bash a nail in with a rock rather than a hammer, but that would be a crazy way to do interviews.

Re: Software Development at 1 Hz

#102

Post by etatoby » Mon, Sep 26, 2016, 12:32 PM UTC

elcct wrote: post #95

userbinator wrote: post #58

Earlier quoted context omitted.

This is exactly the reason why I actually quite strongly discourage teaching programming by starting with IDEs. Far too often I see beginners fall into what I call "programming tunnel vision" where they repeatedly make very tiny and often random changes to a piece of code in an attempt to get it to compile or produce the right result, seeming to completely abandon any thoughts about the overall goal. A lower latency…

I think when you have to resort to using debugger, probably it is better to discard the code entirely and rethink the solution.

I've only used a debugger a few times, when the program did not seem to behave according to the source code. That was invariably due to a third-party bug (compiler, library, OS) or to me failing to understand a subtle point about the language or library I was using.

But in general I agree with you.

Re: Software Development at 1 Hz

#103

Post by mbrock » Mon, Sep 26, 2016, 12:36 PM UTC

elcct wrote: post #95

userbinator wrote: post #58

Earlier quoted context omitted.

This is exactly the reason why I actually quite strongly discourage teaching programming by starting with IDEs. Far too often I see beginners fall into what I call "programming tunnel vision" where they repeatedly make very tiny and often random changes to a piece of code in an attempt to get it to compile or produce the right result, seeming to completely abandon any thoughts about the overall goal. A lower latency…

I think when you have to resort to using debugger, probably it is better to discard the code entirely and rethink the solution.

If you have to break out the multimeter, it's probably just better to throw out that radio and make a new one.

Re: Software Development at 1 Hz

#104

Post by etatoby » Mon, Sep 26, 2016, 12:43 PM UTC

MaulingMonkey wrote: post #92

edejong wrote: post #91

Earlier quoted context omitted.

Java as a language is producing more value to actual businesses than most other popular languages. Where you see an over engineered mess, others see valuable abstractions, extensibility, compatibility and self documentation. Unfortunately, understanding this so called mess requires knowledge of the lingua franca of object oriented design which has fallen out of favour by the new generation. I'm not saying that there…

> Java as a language is producing more value to actual businesses than most other popular languages. Where you see an over engineered mess, others see valuable abstractions, extensibility, compatibility and self documentation. "Everyone uses it" or "it's producing value" doesn't mean it's not an overengineered mess that everyone recognizes as such - it just means that imperfect code still trumps no code. Switching la…

Spring comes to mind as a widely used framework that benefits from those "stereotypical levels of Java abstraction and patterns."

But it's the exception rather than the rule. Once you have something like Spring in your codebase, to take care of modularity and reuse, everything else should be coded with as little "abstraction and patterns" as possible.

Re: Software Development at 1 Hz

#105

Post by mbrock » Mon, Sep 26, 2016, 12:50 PM UTC

lmm wrote: post #99

watermoose wrote: post #41

> At the same time I cannot use toy languages that have no compile time type checking This guy seems like and sounds like a serious developer, so I'm totally confused by this statement. Dynamic languages that don't do compile time type checking are not toys. I used to only write in Java or C++, but I think it's a stage of maturity as a developer to realize that you can develop code that can take arguments with the as…

> If you argue that you need types because otherwise you can't be safe, I'm sorry, but that's like being a helicopter-parent. Sometimes maybe you can't trust what is calling your code even when you give it trust, and that's valid; just like as a parent, sometimes the child really needs that level of micromanagement. But, for a lot of if not most of practical web development, you can use dynamic typing, and most child…

I'm a huge fan of static type systems and their ever helpful checkers.

For me the most difficult argument against static types is that the sweet spot remains elusive: some type systems are too simplistic (e.g. the difficulty of writing generic print in OCaml) while some are too fancy and difficult (e.g. how many people understand even most of GHC Haskell's type system?).

There's also some real problems with compiler error messages. A great type checker needs to be able to explain problems understandably, or decoding the type errors will be more difficult than tracking down a null pointer in an interactive debugger.

I wonder about the possibility of making type checkers more interactive. It can be hard to understand them because they build up lots of implicit understanding that's not apparent.

Re: Software Development at 1 Hz

#106

Post by btbuildem » Mon, Sep 26, 2016, 2:05 PM UTC

fantispug wrote: post #77

castratikron wrote: post #34

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was correct. Make a change, wait five hours, check if the change worked. I eventually started keeping a journal of every code change I made, along with the hash of the binary that it created. I could use this to make several independent changes and run them all at the…

Being methodical is good when your problem is intricate and well defined. Fast feedback won't be helpful in implementing a complex algorithm like a compiler or a numerical simulation (although I would argue it will help you debug it). When what you're doing is simple but error prone, or not well defined fast feedback can make you much more efficient. If you're using an underdocumented API/dataset, the best way to und…

> When what you're doing is simple but error prone

That just means the problem is deeper than your understanding of it.

Re: Software Development at 1 Hz

#107

Post by kabdib » Mon, Sep 26, 2016, 2:10 PM UTC

kyled wrote: post #14

kabdib wrote: post #6

I once had - a super-fast assembler - a super-fast way to get the assembled code over to a target system ... and my turnaround time was on the order of five seconds: Edit, hit a button making the target ready to receive the code, assemble: Running. It almost didn't matter that I was writing 6502 assembly; things just fell together and it was magic . Years later I was in a place where it was common to have half-day bu…

Can you go into more details? Why did something take 30 minutes or longer to build? Was the environment being cleaned every time? Was an artifact server not being used?

I've had long turnarounds (other than the artificial punchcard hell that is really just economics surfaced by IT budgets) in many projects. The ones that come to mind:

- Burning EPROMs for the hardware bring-up of a consumer 68000 machine. Download and burn time for six EPROMs was well over 45 minutes. Things got better when we wrote a downloader, but initial bring-up was kind of painful for a couple of months.

- An unbelievably crappy and development-hostile environment for set-top boxes. Getting 900K of code to a device could take 20-30 minutes, and the transfers often just abjectly failed. "Working as designed" said the people running the head-end. If you wonder why set-top-box software sucks so hard, this is one of the reasons. The whole TV industry is a fractal of shitty practices. Not that I'm bitter. [I did a work-around that let us do dynamic code loading over a different pipe that we theoretically weren't supposed to use "for network stability purposes" and got a biiig bonus after our team's productivity went way up]

- Game development using a cross-assembler on a minicomputer,. The mini was also used as the department's email and office memo system. 45 minutes during the day turned into less than 5 minutes at night, so you can imagine the hours I kept.

- Working on some Windows internals, the less said about this, the better.

The common thread: When bad decisions and designs were institutionalized, things never got better. When it was possible for individuals to improve things, they did.

Re: Software Development at 1 Hz

#108

Post by pitay » Mon, Sep 26, 2016, 2:48 PM UTC

userbinator wrote: post #94

MaulingMonkey wrote: post #75

Earlier quoted context omitted.

"Thinking ahead" is often a great excuse to design an overengineered mess of a solution that can't be tweaked and doesn't really properly solve the problem either. To be pithy - see Java. Sometimes, exploring the problem space can give you a fuller understanding of a problem faster by forcing you to confront pitfalls that may not be obvious until you try a solution. We use all kinds of wonderful terms for this - "Agi…

There's a difference between "thinking ahead into the next problem", i.e. premature generalisation, and "thinking ahead into the details of the current problem". It's good that you mentioned Java, because it is a language which I find extremely IDE-centric, and I suspect that's also what causes easy premature generalisation --- creating new classes with tons of boilerplate automatically generated by the IDE is so eas…

'Fiddle with it until it works' has to be done when you are working with a product that isn't documented well enough. If that mentality is used in general for programming it is bad, but there are some situations where experimentation has to be done to work out how parts the product work.

Re: Software Development at 1 Hz

#109

Post by methyl » Mon, Sep 26, 2016, 3:14 PM UTC

DougBTX wrote: post #18

nojvek wrote: post #9

I am a huge believer of In my new team I got it from 30s to 5s and the effects have been amazing. I have to thank VScode and Gulp to make this possible. With typescript vscode does fast parsing of your code on every keystroke and gives squigglys instantly. On every save, gulp does its magic and vscode runs the problem matcher and shows more squiggly on my editor. The browser knows when a file has changed and refreshe…

This is a problem I'm having at the moment, 20s webpack builds with ts-loader, plus other build steps running in VS 2015. Seems I need to drop ts-loader, and build more directly. Are your build files available to look at somewhere?

Do you run webpack on Windows? It's much slower there than on *nix platforms

Re: Software Development at 1 Hz

#110

Post by cracauer » Mon, Sep 26, 2016, 4:42 PM UTC

watermoose wrote: post #41

> At the same time I cannot use toy languages that have no compile time type checking This guy seems like and sounds like a serious developer, so I'm totally confused by this statement. Dynamic languages that don't do compile time type checking are not toys. I used to only write in Java or C++, but I think it's a stage of maturity as a developer to realize that you can develop code that can take arguments with the as…

I apologize for the swipe at "toy languages". I tried using more common languages like the usual scripting crowd, but it wasn't successful, mostly for performance reasons. Python in particular is frustrating since the very own spec prevents pretty much all optimizations and you can't even call a function without stirring the heap.

I don't advocate a full type-safe language. In Common Lisp I generally don't have to declare any types. The compiler points out obvious, unavoidable type problems that it can deduct, e.g. inside a function that has some typed things such as literals. I can then add types as I like, to both variables and function interfaces, and the compiler points out more.

Another property of Common Lisp is that if you add type declarations they speed up your code if you compile with speed==high and safety==low. But you can also compile your code with safety set higher than speed. In that case a compiler like SBCL turns your declarations into runtime type assertions.

Then you run your automated tests in both modes and you have higher confidence in the code.