Hacker News Reader

Comment by ChrisRR | Hacker News Reader

As a low level developer, i thoroughly disagree. I think it's disappointing that we're given absolutely insane amounts of processing power where intel keep pushing the limits of physics, then developers keep wasting that on inefficient languages like javascript, python, java, etc. They have their uses, but using them to develop every piece of software would be an inefficient waste of resources.

For fast, efficient software there will always be low level languages such as C, C++, etc. and I would always urge more people to learn them, even if just to learn to appreciate how much is managed by their high level language and understand the trade-offs they're making with those languages.

View on HN

> I think it's disappointing that we're given absolutely insane amounts of processing power where intel keep pushing the limits of physics, then developers keep wasting that on inefficient languages like javascript, python, java, etc.

It's called "economics". C and C++ are simply too cumbersome for most applications; most applications don't benefit from that speed (either because the deadlines aren't that critical or because the bottleneck is I/O) and their project deadlines can't afford the velocity tax they impose. Especially when many of those languages allow you to opt out of "slow" features (or FFI into C/C++/etc) for your hot path. Lastly, higher-level languages are improving: Go is probably the easiest language out there and it's almost as fast as C (in the same ballpark, but still slower) and Rust is far, far friendlier than C or C++ but it performs on par.

Not disagreeing but it's interesting that you'd lump Java in with Javascript and Python. Java certainly has its problems but it's considerably faster and more efficient than both.

I'm an embedded C developer. I've not followed Java in years but as far as I knew it was slow, bloated, and full of security holes. I'm very happy to be corrected on that though

Rendering a GUI is much more overhead than the business logic to set up the GUI and make it interactive. A GUI is only "slow" if there is a user-triggered operation that takes more than 10ms. Interpreting a Python callback is many orders of magnitude smaller than this, and complex algorithms can be outsourced to other languages if needed. Focus on your bottlenecks first. Don't pre-optimize.

> Don't pre-optimize.

Don't pessimistically de-optimize either. It's harder to remove bottlenecks from mature applications than it is to plan ahead for the target platform and common use cases.

By all means, prototype in Python but if your target platform is, at minimum, a R-Pi 2 and you want the experience to be snappy even when their is high IO or CPU work being done... then don't release on Python; use the prototype to drive the implementation in C.

Maybe consider even compiling from a higher-level language into a C library to minimize the boiler-plate.

Planning goes a long way, even if you don't plan everything up front.

>It's harder to remove bottlenecks from mature applications than it is to plan ahead for the target platform and common use cases.

I disagree. It's easier to release first and change what you need later, since there might only be 1-10 sections of code that need to be changed. Python is extremely fast to write, maybe 3x faster than C. This means you can get seed funding and sales faster, and if the idea is good enough to get a decent salary, you can just hire out optimization for a v2 release. It also allows your application to appear to get better over time, which makes long-term customers happy.

For a typical SV B2C web application, sure, but we're talking about developing applications for a low-power device.

Knowing your target platform and your end goals can aid in planning. Planning your architecture ahead of time can save you from having to optimize later... and often optimizing later is harder than simply doing the easy, right thing first.

"Low power" or "slow CPU" has nothing to do with it. When you have a bottleneck (GTK, X11/Wayland, video drivers) that is 100x more significant than the binding language (Python), switching languages will only buy you 1% speedup at best. I'm not saying to go forth unplanned. I'm saying that using C over Python in this case is a waste of time.

This is not pre-optimisation. If you start writing your code using javascript, any development on top will continue to be javascript. Until you end up with a full project of javascript and you can't move to C because doing so would mean re-writing an entire project.

> developers keep wasting that on inefficient languages like javascript, python, java, etc

> For fast, efficient software there will always be low level languages such as C, C++, etc.

this sounds like every "low level developer" ever, in that the opinions are completely removed from reality. it isn't 19<whatever>. if by inefficient, you mean slow, then java isn't anywhere near comparable to javascript or python. beyond being a completely different type of language, java is fast. so is c# and f#. so is chez scheme and sml. so are plenty of much higher-level languages than c and safer languages than c++ that are just as fast (if not faster in some cases dependent upon development time and application and developer) than c and c++.

also, c++ is low-level? it is an insanely complex high-level language.

> this sounds like every "low level developer" ever, in that the opinions are completely removed from reality. it isn't 19<whatever>.

Who cares what year it is. Fact is, with low level languages, you can write software which consumes less resources. This won't ever change.

> if by inefficient, you mean slow, then java isn't anywhere near comparable to javascript or python.

Sure, I (and presumably the poster you responded to) agree. Java is plenty fast for most things. But its memory usage is horrendous. Like seriously bad. It seems Intellij takes a solid 1.5gb to simply exist. I'd like to use Java (well, JVM based languages really) more, but basically all JVMs are memory hogs that take too long to start up. Graal might help here, we shall see.

C#, F#, Chez, et al. follow a similar suit. (Chez is probably the best of that lot, though. Would be my choice).

> Fact is, with low level languages, you can write software which consumes less resources. This won't ever change.

and you'll be much more susceptible to bugs and schedule elongation and robustness issues. that won't ever change either.

Reply on news.ycombinator.com