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

521–530 of 819 posts

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

#521

Post by saberience »

dataflow wrote: post #182
eterm wrote: post #180

Earlier quoted context omitted.

It's not "twice as long" in any syntactic sense, and readability is easily fixed: Enumerable.Range(1,50) .Where(e => e % 4 == 0 && e % 3 == 0) .Skip(1) .Select(e => e + 1) That's very understandable, it's clear what it does, and if your complaint is that dotnet prefers to name expressions like Skip rather than magic syntax, we can disagree on what make things readable and easy to maintain.

It's literally "twice as long" syntactically. 120 vs. 67 characters. And again, you keep omitting the rest of the line. (Why?) What you should've written in response was: var y = Enumerable.Range(1,50) .Where(e => e % 4 == 0 && e % 3 == 0) .Skip(1) .Select(e => e + 1) .ToArray(); Compare: y = [t[1] for t in enumerate(range(1, 50, 4)) if t[0] % 3 == 0][2:] And (again), my complaint isn't about LINQ or numbers or these…

The big problem is that while shorter, the Python statement itself looks obfuscated, confusing, and hard to read. C# is a bit longer but way clearer.

For me, that it's possible to write such ugly and hard to understand statements isn't an advantage of a language, it's a foot-gun.

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

#522

Post by skohan »

paskozdilar wrote: post #515
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?

Go fills that spot for me. I've done video4linux stuff in Go, and passing an unsafe.Pointer to a Go struct in an ioctl() worked fine, which tells me that Go structs are isomorphic to C structs. Even though Go has garbage collection, it allocates everything it can on the stack, so only long-lived shared-between-goroutines objects are subject to garbage collection. Go abstracts concurrency, completely removing all conc…

Go strikes me as one of the best "good enough" languages we have right now. You're not going to do HPC in Go, but it's performant enough to run circles around a lot of high level languages and dynamic languages. It abstracts away the stuff that's super error prone about manual memory management, and it's so brutally simple that it's hard for one of your colleagues to write code you're not going to be able to understand.

There's a few features that could improve it, like proper ADT's, and it's a bit lacking in expressiveness for me to choose it for personal hobby projects, but I would recommend it any time for general-case professional software development.

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

#523

Post by knorker »

rot13xor wrote: post #298
knorker wrote: post #54

Earlier quoted context omitted.

Not that it invalidates anything you said, but it was 750ms vs 200 microseconds. But yeah. I agree. Why does Lightroom take forever to load, when I can query its backing SQLite in no time at all? And that's not even mentioning the RAM elephant in the room: chrome. Younglings today don't understand what a mindbogglingly large amount of data a GB is. But here's the thing: it's cheaper to waste thousands of CPU cores on…

Regarding chrome, browsers are basically operating systems nowadays. A standards compliant HTML5 parser is at the bare minimum millions of lines of code. Same for the renderer and Javascript engine.

That's true. I'm not saying a browser solves a small and simple problem. But on the other hand Chrome takes much more RAM than the operating system (including desktop environment).

Even after closing all tabs, since tabs (and extensions) are basically programs in this operating system.

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

#524

Post by blub »

charlie0 wrote: post #69

I've always been tempted to make things fast, but for what I personally do on a day to day basis, it all lands under the category of premature optimization. I suspect this is the case for 90% of development out there. I will optimize, but only after the problem presents itself. Unfortunately, as devs, we need to provide "value to the business". This means cranking out features quickly rather than as performant as pos…

Performance is something that needs to be considered throughout the development cycle. If optimization happens at the end then it’s either a rewrite or a minor concern anyway because the building blocks like frameworks and libraries were already optimized. Or the software is just slow but still sells for other reasons.

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

#525

Post by pjmlp »

bruce343434 wrote: post #483
killingtime74 wrote: post #466

Earlier quoted context omitted.

Transpile to C? Zig or Rust?

You can't just "transpile to C" to get "C speed". C speed comes from low overhead. Naive transpilations will just include that overhead, like garbage collection or many layers of pointer indirection, but written in C. The unsavory answer is that you must use less abstractions if you want fast code. Compilers just aren't good enough to compile all the abstractions away.

That includes C versus modern CPUs.

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

#526

Post by pjmlp »

bayindirh wrote: post #200
bb88 wrote: post #191

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. Writing good C++ is hard. People who think they can write good C++ are surprised to learn about certain footguns (static initialization before main, exception handling during destructors, etc). I found this reference which I thought was a pretty good take on the C++ learning curve. https://www.reddit.com/r/ProgrammerHumor…

> 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,....

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

#527

Post by thorncorona »

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?

Julia is that for a lot of academia + mathematics based code.

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

#528

Post by moffkalast »

paskozdilar wrote: post #515
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?

Go fills that spot for me. I've done video4linux stuff in Go, and passing an unsafe.Pointer to a Go struct in an ioctl() worked fine, which tells me that Go structs are isomorphic to C structs. Even though Go has garbage collection, it allocates everything it can on the stack, so only long-lived shared-between-goroutines objects are subject to garbage collection. Go abstracts concurrency, completely removing all conc…

He said "easy to read" not "filled with weird syntax choices that make anyone from a C background barf". What the hell are those channel arrows and why do they point the wrong way.

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

#529

Post by moffkalast »

qikInNdOutReply wrote: post #509
flohofwoe wrote: post #485

Earlier quoted context omitted.

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…

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.

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

#530

Post by ZoomZoomZoom »

sklopi wrote: post #441
edbaskerville wrote: post #121

Earlier quoted context omitted.

The thing that did for me is realizing that people on opposite sides of the United States can't play music together if it requires any rhythmic coordination, even with a true speed-of-light signal with no other sources of latency.

You could have a metronome in the middle

It is actually the way to go with client-server programs, such as Jamulus. People from distant locations try to chose/run a server closer to their geographical (or, more properly, with a correction on how the fiber runs) middlepoint.
Post reply on HN