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

The computers are fast, but you don't know it

shvbsle.in

Post reply on HN
Print view View original

531–540 of 819 posts

Re: The computers are fast, but you don't know it

#531

Post by bayindirh »

pjmlp wrote: post #526
bayindirh wrote: post #200

Earlier quoted context omitted.

> I've seen a lot of bad C++ in my life, and have seen Java people write C++ like they would Java. Ah, don't remind me Java people write C++ like they write Java, I've seen my fair share, thank you. > Writing good C++ is hard. I concur, however writing good Java is also hard. e.g. Swing has a fixed and correct initialization/build sequence, and Java self-corrects if you diverge, but you get a noticeable performance h…

> Ah, don't remind me Java people write C++ like they write Java, I've seen my fair share, thank you. I always find this remark amusing, given that Java adopted the common patterns in C++ toolkits that precedded Java. If anything they are writting C++ like it used to be on Turbo Vision, Object Windows Library, MPW, PowerPlant, MFC, wxWindows,....

The remark is rooted from variable naming and code organization mostly. I've seen a C++ codebase transferred to a java developer, and he disregarded everything from the old codebase. Didn't refactor the old code, and the new additions were done Java Style. CamelCase file/variable/function names, every class on its own file with ClassName.cpp files littered everywhere, it was a mess.

The code was math-heavy, and became completely unreadable and un-followable. He remarked "I'm a java developer, I do what I do, and as long as it works, I don't care".

That was really bad. It was a serious piece of code, in production.

Re: The computers are fast, but you don't know it

#532

Post by carlmr »

moffkalast wrote: post #529
qikInNdOutReply wrote: post #509

Earlier quoted context omitted.

So a good language, should not abstract that memory pyramid away, but instead make you painfully aware of it, while developing. Rewarding DOD, punishing OO, but that results in more education time for programers, which no company is willing to pay for. What instead is needed is a intermediate language, that takes the constructs of object orientation and the instruction flow and allows to rearrange them for maximum me…

> that results in more education time for programers, which no company is willing to pay for That's why you finally stop teaching Java in high schools.

I was going to say OOP aside from the basic animals and calls example, takes years of indoctrination for people to find it the simple default way to do things.

Functional programming is much simpler, but we don't spend years hammering the concept into people's brains.

Re: The computers are fast, but you don't know it

#533

Post by xigoi »

anfelor wrote: post #518
ano88888 wrote: post #462

Earlier quoted context omitted.

Why can't we have a language easy to read and maintain but also have the speed of C?

Ocaml 5 and Koka ( https://koka-lang.github.io/koka/doc/index.html ) can get quite close to the speed of C...

Unfortunately, Koka doesn't seem to be ready for general-purpose use…

Re: The computers are fast, but you don't know it

#534

Post by necovek »

ruined wrote: post #423
scarmig wrote: post #266

Earlier quoted context omitted.

Perhaps the solution is more on the bioengineering side of things: make smaller people so they can fit in smaller rooms.

this has been tried before. the vast majority of the smaller people that get made simply keep getting bigger until they become normal size.

We need to make them make even smaller people before they grow (up? :)!

Re: The computers are fast, but you don't know it

#535

Post by xigoi »

ano88888 wrote: post #462
skohan wrote: post #453

I remember the moment I realized how fast computers are at uni. I was in an algorithms course, and one of our projects was to make a program which would read in the entire dataset from IMDB of films and actors, and calculate the shortest path between any actor and Kevin Bacon using actors and movies as nodes and roles as edges. I was working in C, and looking back I came up with a quite performant solution mostly by…

Why can't we have a language easy to read and maintain but also have the speed of C?

We can.

https://nim-lang.org/

Re: The computers are fast, but you don't know it

#536

Post by jayp1418 »

ano88888 wrote: post #462
skohan wrote: post #453

I remember the moment I realized how fast computers are at uni. I was in an algorithms course, and one of our projects was to make a program which would read in the entire dataset from IMDB of films and actors, and calculate the shortest path between any actor and Kevin Bacon using actors and movies as nodes and roles as edges. I was working in C, and looking back I came up with a quite performant solution mostly by…

Why can't we have a language easy to read and maintain but also have the speed of C?

Ada Programming Language

Re: The computers are fast, but you don't know it

#537

Post by loup-vaillant »

fullstackchris wrote: post #343
munificent wrote: post #68

Earlier quoted context omitted.

I agree 100%. I wish every software engineer would spent at least a little time writing some programs in bare C and running them to get a feel for how fast a native executable can start up and run. It is breathtaking if you're used to running scripting languages and VMs. Related anecdote: My blog used to be written using Jekyll with Pygments for syntax highlighting. As the number of posts increased, it got closer and…

While I'll take a bite at this, I think it's also fair to say how poorly portable C is. Can an mobile or web engineer quickly take some C code and use it in their stack somehow? I would guess not. While it's indeed an important lesson to see the speed of some of these 'close to the metal' languages, the question of how practical they are to use is a different question.

There is a class of C code that can be made extremely portable: pure computations. This allows you to write self contained code with zero dependencies, and if you're willing to give up on SIMD you can stick to fully conforming C99.

It's not applicable for everything, but we do have some niches where it comes in handy: cryptographic libraries (I've written one), parsers and encoders of all kind, compilers…

For instance can a mobile on web engineer quickly take TweetNaCl or Monocypher and use it in their stack? Yes. They may need to write some bindings themselves, but if they can run C code at all it's fairly trivial.

Re: The computers are fast, but you don't know it

#538

Post by m1el »

journey_16162 wrote: post #514

As a front-end developer, I can't help but notice how much useless computation is going on in a fairly popular library - Redux. It's a store of items, if just one tiny items change in the whole store, every subscriber of every item gets notified and a compare function is ran to check if it changes. Perhaps I'm misunderstanding something and not to bash on Redux - I'm sure there are well-deserved reasons it got popula…

Hi, I believe I understand you. If you look at immutable data structures implemented using JS primitives, it will surely look terrible. However, there's a lot of benefit to using a FP approach like Redux.

It's much easier to reason about state updates if all you have is pure functions. It allows you avoid very annoying and hard to catch bugs. I've seen this personally, when replacing a spaghetti component with a straightforward `useReducer` hook.

Unfortunately, we don't really have a performant way to express this pattern in JS (or even in other languages?). You could use something like elm-lang, but it's not as widespread.

Re: The computers are fast, but you don't know it

#539

Post by bbojan »

SekstiNi wrote: post #34
bbojan wrote: post #18

Earlier quoted context omitted.

I recently ported some very simple combinatorial code from Python to Rust. I was expecting around 100x speed up. I was surprised when the code ended running only 14 times faster.

Just to be sure, you did compile the Rust program using the --release flag?

Yup!

Re: The computers are fast, but you don't know it

#540

Post by dzaima »

flohofwoe wrote: post #485
ano88888 wrote: post #462

Earlier quoted context omitted.

Why can't we have a language easy to read and maintain but also have the speed of C?

It's not "the C part" that makes code run fast, but memory access patterns. C just happens to not get in the way between the coder and the machine when it comes to explicit control over memory layout. In the late 60's and early 70's this was probably an "accidential feature", but with the widening CPU/memory performance gap it turned out that later languages (from the late 90's and early 00's) had bet on the wrong ho…

It's not even just memory access patterns. It's any and all abstractions - C doesn't provide any, so you write things manually, and thus won't do things that are not required for your use-case (whether it be separated loops for actions, pre-initialization/zeroing, multiple allocations where one or none could do, and higher-level stuff like no need for iterator stability, a vector push that assumes reserved space, etc).
Post reply on HN