Hacker Newsnew | past | comments | ask | show | jobs | submit | rogue7's commentslogin

what are you talking about ?


Kind of agree, but in my view preventing the programmer to make mistakes is futile. I have seen awful stuff in languages made to prevent errors.

It's much better to give all the power to the programmer, to allow him to fix his mistakes rather than fantasising about preventing them.


I'm not big on static type checking in most situations -- adequate testing should find the type errors too -- but one place it looks very useful is avoiding data races in multithreaded programs. See Rust.


... or Ada.


IMHO surveillance is a problem when it is asymmetric ; which is obviously the case here. Governments for example are watching everyone inside and outside, but the people that are being monitored simply cannot really watch the people watching them. Don't you agree ?

In this view, maybe an ultra radical solution to privacy issues is : no privacy at all, for no-one. Complete and total transparency of everyone to everyone. Now the question is how to implement that ? That's obviously impossible, because someone in power will always have something to hide. So maybe if true democracy where everyone holds exactly the same amount of power that could work ? Same issue, because it is impossible to implement too. Oh well.


That is a "justifies extreme violence to prevent" type suggestion. Privacy is a basic human right. The problem is power. No one should be in a position to spy on everyone.


Agreed for cheaper prices and more flexibility. At least this is what we think we want. But do we actually want it ? A computer 40 years ago was way more expensive than now. How did people do it ? They managed. How do we do it now ? We manage, similarly.

Was there an improvement in things ? Obviously, computers are more powerful for example. But with less powerful computers, people could also be happy I believe.

I remember 15 years ago, tech has obviously evolved a lot since then, and I have learned to use more and more tech tools. But am I more efficient than then ? Happier than back then ? More skilled than back then ?

- More efficient for some things, less efficient for others. - Happier ? no. Not sadder either, similar. If anything, it's not related. - More Skilled ? No. Skilled at other things. For example my handwriting is still ok but I believe I won't be able to write so much or so quickly or so well as I used to (I should try though).

Am I saying that progress is not real ? No, of course not. Progress happens. But is it what "people" want or need ? Taking my own perspective : if it happens (and it does), I adapt - no problem. If it does not happen somehow - then I would adapt too. That's what we do.


Personally, it depends. If I could automate taking the trash out, I would do probably want to do it (not sure though). But what remains when everything is automated ?

Well, so far we have been automating many things, and we are still busy working and living as always. It's of course impossible to automate everything - we always have things to do, by necessity by also by choice ; do we really want to be idle and contribute nothing to society ? I don't, and I am sure nobody does. Being useful is an essential need.

Is it pointless then, to automate more and more ? No. It's a way to move forward, and not necessarily a "bad" way. Just not the only way.


> But what remains when everything is automated?

The answer has been perfectly captured in this czechoslovakian cartoon made in 1984. https://youtu.be/6Mo8gQ89aEA?feature=shared


I shouldn't admit it, but when you described a czechoslovakian cartoon about automation, my first thought went straight to this: https://www.youtube.com/watch?v=z2_dhUv_CrI&t=14s


There is also the film Zardoz.


Never heard of this joke, very funny !


For this I use gron [0]. It's very convenient.

[0]: https://github.com/tomnomnom/gron


This looks neat. However since I read about Koka's dot selection [0], I keep thinking that this is an even neater syntax:

fun showit( s : string )

  s.encode(3).count.println
However, this is of course impossible to implement in most languages as the dot is already meaningful for something else.

[0] https://koka-lang.github.io/koka/doc/book.html#sec-dot


It is called Uniform [Function] Call Syntax.

D has had this for decade(s): https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...

Nim too has it: https://nim-by-example.github.io/oop/


That syntax is very clean when it works. I think however the limitation of not being able to pipe arguments into 2nd, 3rd, ..., positions and keyword arguments, or variadic explosion like the syntax showcased in the article makes it less powerful.

Are there other syntax helpers in that language to overcome this?


It still makes sense to have a clean syntax for the simple case. You can use currying (with or without first class language support) to handle more complex cases or just fall back to good old function composition or even loops.


I think this is called uniform function call syntax.


I built a small static web app [0] (with svelte and tensorflow js) that shows gradient descent. It has two kind of problems: wave (the default) and linear. In the first case, the algorithm learns y = ax + b ; in the second, y = cos(ax + b). The training data is generated from these functions with some noise.

I spent some time making it work with interpolation so that the transitions are smooth.

Then I expanded to another version, including a small neural network (nn) [1].

And finally, for the two functions that have a 2d parameter space, I included a viz of the loss [2]. You can click on the 2d space and get a new initial point for the descent, and see the trajectory.

Never really finished it, though I wrote a blog post about it [3]

[0] https://gradfront.pages.dev/

[1] https://f36dfeb7.gradfront.pages.dev/

[2] https://deploy-preview-1--gradient-descent.netlify.app/

[3] https://blog.horaceg.xyz/posts/need-for-speed/


> It has two kind of problems: wave (the default) and linear. In the first case, the algorithm learns y = ax + b ; in the second, y = cos(ax + b).

Are "first" and "second" switched here?


Vaping is way less harmful than smoking.

See e.g. the study [0] conducted by Public Health England that concludes vaping is at least 95% (!) less harmful than smoking.

See also this video [1] that shows graphically the different impact it has on the lungs.

[0] https://www.gov.uk/government/news/e-cigarettes-around-95-le...

[1] https://youtu.be/0Pwj6BuS8Ds


  > independent study
  > at least one author has relations with Ruyan group (today part of Imperial Tobacco), a then-major vape manufacturer
  
But even this "independent study" seems to acknowledge the difference between recreational vaping, and using vape as a tool to stop smoking.

Do you believe everything that's on TV, or are you just a run of the mill tobacco company shill?

The only reason I want to live until 2050 is to see the lawsuits that will mirror the smoking lawsuits from the early 90s. (But this time they will be lead by Instagram and TikTok influencers - not that it will take any of the value)


Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: