Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Development at 1 Hz

medium.com

Post reply on HN
Print view View original

91–100 of 121 posts

Re: Software Development at 1 Hz

#91

Post by edejong »

MaulingMonkey wrote: post #75
RandomOpinion wrote: post #61

Earlier quoted context omitted.

Are you genuinely attempting to argue that thinking ahead and fully understanding the problem isn't preferable to tweaking one's way to a solution?

"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…

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 are no unjustifiable over engineered java libraries, but the current hype cycle of web frameworks seem to indicate the burden of proof of good design should lie with current technologies as well as previous.

Re: Software Development at 1 Hz

#92

Post by MaulingMonkey »

edejong wrote: post #91
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…

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 languages usually means tossing out your old codebase, leaving you at "no code".

I have worked on such messes, created such messes (oops!), and cleaned up such messes.

That said, I'm sure there is a Java project out there which actually benefits from stereotypical levels of Java abstraction and patterns - and I'm sure there's a few codebases out there where "my" and "others" opinions differ exactly as you say.

> I'm not saying that there are no unjustifiable over engineered java libraries, but the current hype cycle of web frameworks seem to indicate the burden of proof of good design should lie with current technologies as well as previous.

100% agreed - not that I'm qualified enough at web dev to have much of an opinion on this. If anything, the churn of web frameworks smacks of being both overengineered (do you really need a whole framework for that?) and underengineered (wait why are we replacing things yet again?) simultaneously.

Re: Software Development at 1 Hz

#93

Post by agumonkey »

FreeFull wrote: post #69
agumonkey wrote: post #19

Earlier quoted context omitted.

I always laugh thinking that Turbo Pascal was so quick I didn't understand the difference between build and "build then run". And that was statically typed code on Pentium class computer.

I think Pascal was specifically designed in a way that allowed a compiler to go straight from the source code to machine code in just one pass (although the output wouldn't be particularly well optimised).

True, I've read that they made both the syntax easier to parse, and kept the compiler relatively simple to avoid intermediate structures/allocations etc.

I took a look at Wirth first Pascal compiler too, it's just too files, of acceptable length, lot of coupling though, but it's easy to guess that it's an imperative style that brings a lot of mechanical sympathy.

Re: Software Development at 1 Hz

#94

Post by userbinator »

MaulingMonkey wrote: post #75
RandomOpinion wrote: post #61

Earlier quoted context omitted.

Are you genuinely attempting to argue that thinking ahead and fully understanding the problem isn't preferable to tweaking one's way to a solution?

"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 easy that it encourages programmers to. That doesn't help one bit with the details of the algorithm, unfortunately; it often gets "OOP-ified" into a dozen classes and much-too-short methods created as a result of the "fiddle with it until it works" mentality.

Re: Software Development at 1 Hz

#95

Post by elcct »

userbinator wrote: post #58
darthdeus wrote: post #47

Earlier quoted context omitted.

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. This! People rely on their fancy REPLs and super fast feedback loops and 1000 unit tests too much these days. What do you actually do when you can't run the code? What if you have to debug it just by reading it? There's a lot to be said about being efficient with trivial changes vs being methodical…

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.

Re: Software Development at 1 Hz

#96

Post by lmm »

RandomOpinion wrote: post #61
WhitneyLand wrote: post #60

Earlier quoted context omitted.

>>"I quite strongly discourage teaching programming by starting with IDEs..." >>"...also happens if you give them a debugger..." 1). I assume you can cite no research supporting the idea that new programmers are better off with your recommendations? 2). Your idea doesn't seem to take into account that different people think in different ways. I believe this approach was good for you. But as far as we know you could b…

Are you genuinely attempting to argue that thinking ahead and fully understanding the problem isn't preferable to tweaking one's way to a solution?

If they won't, I will. Working code (in a good language) is the best way to work on the problem, far better than a whiteboard where you have no undo, no VCS tagging, no ability to come up with reusable components... . Trying to do it all in your head would be even worse.

Of course it's possible to push code around on the page until it seems to work, just as it's possible to push symbols around the page until it seems to work when answering a mathematical question on paper. (Unfortunately some languages/compilers will run code that doesn't make any sense, but that's more true on paper, not less)

Re: Software Development at 1 Hz

#97

Post by lmm »

eeks wrote: post #4

A 20s turnover is not even that slow. Debugging undecidable timing issues in an FPGA may have turnover counted in hours given how slow HW synthesizers are. If the need of better tooling is clear, the OP does not mention one important point: faster machines have created some sort of fast food approach to programming, where programs are built on the go with the help of the appropriate tools (some sort of computer-aided…

A design board is just another tool, a workaround for not being able to run the program quickly enough (compare e.g. "presentation compilers" in languages that take a long time to fully compile).

Re: Software Development at 1 Hz

#98

Post by lmm »

taeric wrote: post #74
StavrosK wrote: post #39

Earlier quoted context omitted.

> debugging first in your head is yet another skill that should really be taught to everybody but isn't Along with smelting iron. I don't know why people advocate skills one doesn't need, saying "but they make you better". Skills you don't need will atrophy, because you don't need them. Conversely, skills you need with strengthen. Why would I debug first in my inaccurate head when I have a perfectly accurate debugger…

This is as silly as asking why people advocate exercise. I mean, you clearly don't need to be able to lift heavy things. Even if it is sometimes helpful. Similarly, thinking about things before you do them will almost always be something you could just skip out on. But... It can be very helpful. And exercise is a great way to get better at work. "Practise makes perfect" and all.

No, people advocate exercise because it's necessary for long-term health.

Re: Software Development at 1 Hz

#99

Post by lmm »

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 children do not need that level of micromanagement.

This is backwards. Working without types is like walking around with your eyes closed: sure, you can do it, most of the time; if you're not doing anything particularly dangerous you can even do it reasonably safely. But it makes everything a lot slower.

The arguments against types usually boil down to either, as the saying goes "The belief that you can't explain to a computer why your code works, but you can keep track of it all in your head", or having only used languages where the explanation to the computer is so cumbersome as to not be worth doing (valid, but only in the scope of those languages, and the correct response is almost always to get a better language).

Try using a language with a decent type system some time (something along the lines of OCaml, Haskell, F# or Scala). Back when I'd only written Java and C++ I also thought type checking wasn't worth it.

Re: Software Development at 1 Hz

#100

Post by Retric »

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…

The problem is fast feedback means you tend to create more bugs. It's faster in the short term, but very quickly produces unmaintainable code.

In the end you can write code to be read (aka maintainable), to be run (aka fast), or to be written (aka cheap).

PS: Sure, in theory it's simply better. However, people get lazy make some change and assume if it's passing their tests it works.

Post reply on HN