For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more scscsc's commentsregister

I am surprised so many talented engineers went the touchscreen route. Volkswagen, Mercedes and more recently BMW are going this way. In my experience it is not only annoying, it is a safety hazard. In my old car, I could feel for the button to turn on the defrosting without ever taking my eyes off the road, it was so well designed!

In a way, it feels that the current trend is very much like the Apple laptops at some point, where they god rid of the physical function keys and replaced them with touch sensitive controls. Thankfully, Apple is reverting this change.

I think at some point car manufacturers will realise that it leads to more accidents and they will also reverse course. Perhaps touchscreens will even be forbidden?

Caveat: I was wrong before on touchscreens. I though phones with touchscreens will not work out, but they have. However, it is because we no longer use phones for phoning, but to watch movies, read text, etc.


I don’t believe for a second that engineers are driving the decisions to use touchscreens. Collectively, engineers have ethics that would prevent dumpster fires like this.

No, I blame the managers and executives, looking to add feature while reducing costs. Moreover, adding this level of software integration permits later adding software locks via an OTA update.

Auto execs wouldn't know ethics if they bit them in the ass. Those individuals should be held responsible for the tragedies that their reckless choices have caused.


I have an anecdote to offer: in the early 2000s I was learning to drive in a former comunist country. Most cars were Dacia 1310, a copy of 1970s Renaults. The stick was awful, the steering was very heavy (as in lifting weights heavy), the clutch was terrible. It was very difficult to drive one, let alone learn to drive one. Newer and better cars were just beginning to appear, but there were few of these and they were expensive. There were two lines of thought in my circle: (1) that you should learn on a Dacia, because then you will be able to drive anything and (2) you should learn on a modern car, because it is easier. Needless to say, camp (2) won: the Dacias all but disappeared and furthermore, newer cars are mostly automatic.

So I wouldn't hold my breath that the manual gear shift will survive.


> the steering was very heavy (as in lifting weights heavy)

The 1310 didn't have power steering :)

But it can be worse. You could try driving a 2 ton Mercedes with non functional power steering. That's a sweat inducing task.

Anyway, with no power steering you have to keep the car moving at a snail's pace when turning the wheel. No adjusting wheels in place if you're not up to date with your weight lifting. This skill got lost before the skill to drive a manual.


When a field is young, it is simpler to make important discoveries, so in that sense, science is (obviously) getting harder.

But most of the graphs can be explained by the sheer number of papers being published.

Academics have the perverse incentive to publish as many papers as possible, instead of discovering as many interesting things as possible, because items published is way easier to measure than real progress made.

Therefore there is a significant paper inflation problem. People might today write 10 papers with LPUs (least publishable unit) with stuff that would have been a single technical report 30 years back.

This is much worse than it sounds, because it affects productivity significantly in subtle ways: it takes effort to publish those 10 papers, it takes effort to read up and review the 10x papers of others, and it takes time to think about LPUs instead of concentrating on the bigger picture.

Unfortunately, due to the way the research system is set up, it is not likely things will improve.


I am skeptical that a book can substitute for a mentor (or teacher) at the start of someone's dive into mathematics.

Once you know your basics, sure, go study a book. But by this point, you already know whether a given book helps you or not...


The internet has become larger.

People's attention is more dispersed (additionally, several platforms are actively fighting for their attention by using all tricks in the book).

Hence the signal-to-noise ratio has dropped. The people who would leave thoughtful comments are busy with other things.

A few communities still stand (hacker news included).


While losing weight, I would not replace it, but simply remove it altogether. Bread is not an essential nutrient (although obviously French baguettes are great tasting). You can get plenty of carbs from other food (e.g., fresh fruit).


You are probably thinking of F#, not F*. Very different languages.


"Programs written in F* can be translated to OCaml, F#, and C for execution. ... The latest version of F* is written entirely in a common subset of F* and F#, and bootstraps in both OCaml and F#."[1]

https://en.wikipedia.org/wiki/F*_(programming_language)


I’m not sure what point you’re trying to make with that quote. The languages that F* can be compiled to and the ones it’s written in aren’t relevant to what was being discussed.


Why is that relevant though? You could also write a version of (for example) Prolog or Forth or Lisp using OCaml that would compile to OCaml for execution. Doesn't mean any of those are OCaml. Coq isn't OCaml. Haxe isn't OCaml. The fact that F* is written in, uses a subset of the syntax of and can be compiled to F# (or OCaml) is an implementation detail, the language and the purpose of the language aren't to be OCaml/F#.


The key here is "it looks like they are equivalent".

In fact, I am not sure they are equivalent (in general, without taking into account the context), and even if they were, proving this would be S.F. for a compiler today (2020). Even coming up with such an optimisation without hardcoding it does not seem plausible.


You are probably right regarding speed, but the article is definitely not pointless and bad.


That looks interesting. The code is not simpler to understand nor is it more efficient, but it seems to work, assuming target is in the list. How would you represent the empty list?

Not sure why you are being downvoted.


The representation of the empty list does not change, it's still an IntList object with a null Head field.

The downvotes probably come from my blatant disregard of the real-world performance in the search of what I considered the real take-away from the article.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You