Hacker Newsnew | past | comments | ask | show | jobs | submit | onemoresoop's favoriteslogin

Jaron Lanier is a frustrating thinker. In general he's a pessimist and highly critical of AI and technology. I was at talk of his and asked him about open source AI models and suggestions for ethical frameworks to guide AI research. He gave a rambling answer about we need to pay all the human annotators ever involved in producing a model and that AI is fundamentally anti-human. His justification was as an odd anecdote about an elementary student asking what's the point of human life if robots will do everything in the future. Jaron doesn't provide a meaningful way to engage with his critique and it seems the logical conclusion of his view is that we abandon technology all together.

I do agree with the underlying claim that modern AI research erases the human effort (everything from Mturkers to exploited labor) in producing the annotations that most AI system rely on. It's also fair the critique the proliferation of surveillance states and authoritarian governments that build upon and fund current AI research.

There is isn't good ethical guidance and frameworks to help researchers navigate doing research and in understanding the implications of their works. I'd prefer critiques of AI help guide some sort ethical framework for understanding, developing, and deploying these technologies responsibly. I don't think we can just stick our heads in the sand and pretend the problem goes away or abandoning AI in liberal democracies somehow stops authoritarian regimes from building even worse things.


I think the thing I'm most excited about is the increase in _user prompting_.

If I give a poorly constrained/ambiguous prompt, I don't want the model one-shotting assumptions left and right.

The demos of Fable/GPT-6 are impressive, but "real AGI" should act more like a collaborator than either a peon or overachiever.

It's a tough balance to get right, and although this has been possible to achieve with additional prompting on existing models, I find that the agents often lean too hard into the "ask questions" mode.

Hopefully this model has the right balance, or at least better?


I have strong opinions on how Calc should be introduced - visually.

I think we don't cover basics like the distributive rule in school very well, and that it should be a much more nuts n bolts visual / measuring / counting experience.

Ive attempted to outline how I think this stuff should be taught, by making a video tour of the concepts - from Counting, to Distributive rule / algebra, to Quadratics then the Derivative, here :

https://www.youtube.com/playlist?list=PLEInJ-Z4qBKYxbK1Mm13g...

All of these things are covered in some great books :

  W W Sawyer Vision in Elementary Mathematics
  Algebra by Gelfand
  Calculus by Thomas
We have superb resources now like 3Blue1Brown, KhanAcademy and ArtOfProblemsolving.com / BeastAcademy .. so you _can_ get your kids a superb math education, even as many schools seemingly give up on teaching Algebra and Calculus.

This March 2025 post from Aral Balkan stuck with me:

https://mastodon.ar.al/@aral/114160190826192080

"Coding is like taking a lump of clay and slowly working it into the thing you want it to become. It is this process, and your intimacy with the medium and the materials you’re shaping, that teaches you about what you’re making – its qualities, tolerances, and limits – even as you make it. You know the least about what you’re making the moment before you actually start making it. That’s when you think you know what you want to make. The process, which is an iterative one, is what leads you towards understanding what you actually want to make, whether you were aware of it or not at the beginning. Design is not merely about solving problems; it’s about discovering what the right problem to solve is and then solving it. Too often we fail not because we didn’t solve a problem well but because we solved the wrong problem.

When you skip the process of creation you trade the thing you could have learned to make for the simulacrum of the thing you thought you wanted to make. Being handed a baked and glazed artefact that approximates what you thought you wanted to make removes the very human element of discovery and learning that’s at the heart of any authentic practice of creation. Where you know everything about the thing you shaped into being from when it was just a lump of clay, you know nothing about the image of the thing you received for your penny from the vending machine."


This piece changed how I work with LLMs and made me much more optimistic about how "fun" it can be to work with them: https://nolanlawson.com/2026/05/25/using-ai-to-write-better-...

Before I would just throw prompts at the LLM and it'd end up building a pile of crap (but semi-working crap, and 100x faster than I ever could) - it was pretty depressing. Using tools like `grill-me` (or `grill-with-docs`) I feel like I'm actually building my understanding of the system and helping shape it, and the results are much better.


True but I don't think we've reached the limit.

This is why I advocate for people to spend some time outside in nature and try to do something different once in a while because it's so easy to get stuck in a really small bubble. Especially when you exist in an entirely man-made, soon-to-be fully AI-controlled environment. You may lose your ability to have novel thoughts.

Some people are already there but the range of thoughts seems to be narrowing.

My biggest fear is being caught up in such group for financial reasons and trying to navigate some kind of linguistic and conceptual minefield everyday. I already encountered a situation like that twice in my career. Very tense environment. Feels like you're in a brainwashing cult and have to pretend to be one of them; it's really hard to pretend to be ignorant of certain kinds of information when you don't know what the full range of forbidden ideas is. Saying the wrong things got me fired both times; differences in our mental conditioning created very subtle tension/discomfort between me and management.

They will tolerate people who are 'running a simpler program' than themselves but they will absolutely not tolerate someone with a broader programming. Hence you have to pretend to be narrow-minded which is hard to maintain. This is why I like remote work.


For me the question often is, how can I keep from singing badly on recordings? I've had enough vocal lessons to know that I'm not a naturally great singer. I have poor tone, even worse control, and my vibrato sounds ... bad.

Time adjustments: I use Logic's "flex time" for this. Having your vocals land crisply on the beats you're aiming for really improves the sound of things musically. It also helps in the next step.

Comping: Comping is where you create a good composite track out of a bunch of mediocre ones. Swipe-to-comp in Logic is pretty great, the way it does auto fades between comp sections to avoid zero-line crossing clicks and pops really helps.

Tuning: I use flex in Logic. I try not to overdo it, you can easily introduce bad-sounding tuning artifacts if you're not careful. I have to force myself to not attempt to tune every note, just the really wrong ones. It helps to map out the notes of the melody that's in your head on another instrument.

Double up: Once you have a bunch of unique tuned comps that are mostly time aligned to each other, you can thicken the sound a lot by layering them. Choruses need big vocals right? You can use your extra tuned and tightened tracks to double (or triple, quadruple) up your vocals and pan them left/right to make them sound bigger and better. Because they're unique tracks and not copies this will sound wide, and because you left in some minor timing slop, it will sound tight, but not robotic. You can also use doubles in non-chorus parts to emphasize certain words or phrases.

Harmony: Harmony tracks can really sweeten and thicken a vocal. It'll definitely help to learn some music theory to understand the right notes for your harmony parts, but you can also just do it by ear. I take a one of my comps, and push the notes around with tuning software so it becomes a harmony against the lead vocal. Sometimes these extreme tuned artificial harmonies can sound robotic, but if you blend them in subtly and/or play with the formants they can work well. If not, you can use them as a guide track to re-record organic parts, but that's more work. Use harmony parts the same way you might use doubles.

Even if you can't sing well, you can still make pretty good vocal music these days using technology.



I've been thinking about something related lately.

I've been going through algorithms problems and although I've been a very successful engineer, I feel terrible when solving algorithms problems.

I had a realization, which is that there are two ways to learn:

1. trying to figure out solutions a priori

2. learning from tutorials online or cormen, rivest, stein, etc.

The two approaches are very difficult for me to reconcile. I'm the type of person that always prefers to do (1). That said, a lot of algorithms probably either

1. took a lot of careful studying to figure out

2. were solved by someone who is really brilliant

3. some combination of (1) and (2)

I think we need to remember that in all likelihood, many "solved" problems in technical fields -- which individuals are expected to be able to solve, at least in programming interviews -- probably were solved in the past by taking a lot of careful time by reasonably smart (but not necessarily genius individuals -- though I am sure there are exceptions).

I would much prefer to be able to do (1) for every algorithms problem, but the fact of it is, I think it is near impossible (probably even for very brilliant individuals, maybe folks like Ramanujan excepted -- and even then, he had exposure to building blocks in textbooks).

Calculus is a special case of this, for example. It doubtless took Newton and Leibniz a lot of very careful studying to discover calculus in addition to them being very bright individuals.

Solving a rubik's cube is another example. I suspect (though am not sure) that the the number of individuals who have solved a rubik's cube a priori is extremely tiny. Maybe on the order of dozens (out of hundreds of thousands if not millions?) in the world ever.

I don't think that these issues are clearly articulated enough and it really is a shame.

It's also a tragedy, I think, that we live in a world where:

1. individuals working in technical fields are often expected to be able to know how to do a lot of very hard things that likely took humanity a very very long time to discover

2. there is a tremendous amount of pressure in many contexts to know how to do very hard things in many cases without very much support in learning

For individuals that don't care too much about figuring things out a priori, I think this can be a very very challenging world.

I think one of the ways out is to appreciate the above -- and to carefully, slowly, thoughtfully attempt to reconcile when to try to understand things a priori versus when to try to learn things from principles others have discovered.

The first individuals who were doing things like sorting algorithms, dynamic programming, etc. likely took months if not years to be able to solve problems that are now considered (relatively) trivial and in only a few lines of code.


I agree that reasoning and consciousness are different, however what I do not see being discussed by the AI research community is the necessity to define and then develop "artificial comprehension".

At this point in time, the act of comprehension is a scientific mystery.

I'd say 'consciousness' is the ongoing ever present comprehension of the moment, a feedback self conversation assessing the current situation a being finds itself. This act requires reasoning, as comprehension is the "sandbox" in which reasoning occurs.

But what is comprehension? It's the instantaneous reverse engineering of observations for verification of reality: is what I observe normal, possible or a threat? If one cannot "understand" an observation then the potential the observation is a threat grows. That 'understanding" is reverse engineering the observation to identify it's range of possible behavior and therefore one's safety in relation to that observation.

Comprehension is extremely complex: arbitrary input goes in and a world model with one's safety and next actions comes out.


"every team working to improve the customer experience - guided by leadership priorities and initiatives"

The fundamental issue is that in almost all larger companies, upper management does not trust that their employees are either intrinsically motivated to do a good job, or are smart enough to determine what "a good job" is.

So rather than having a chain of trust from upper management to middle management to individual contributors, they seek to create a measurable control system. This inevitably replaces people's intrinsic motivation to do a good job with an extrinsic motivation, which only poorly represents the company's actual goals. At this point, most people are no longer trying to do a good job, they're instead trying to make their numbers look good.

Upper management has effectively replaced real, meaningful work with a game where everybody tries to score points, and the people who don't participate in that game are eventually stackranked out of the company.


The article's implicit conceit is that a bureaucracy is just an attempt to abstract away what is in actuality a bunch of distinct self-interested obstructionist fiefdoms — that each do all they can to prevent the organization from

1. doing anything that would pose an existential threat to the fiefdom,

2. starting any project that would be the fiefdom's ultimate responsibility to deliver upon,

3. reorganizing in a way that would cause the the fiefdom's "slack", or continued underperformance (compared to the organization's usually-unrealistic expectations) to be made more legible,

4. doing anything to equalize and redistribute any special advantages that come with the fiefdom's existing responsibilities,

...and so forth.

The CIA sabotage manual applies perfectly to the usual sort of bureaucratic organization full of such fiefdoms, as such fiefdoms use exactly these techniques to prevent the projects that would threaten them from moving forward (at anything beyond a glacial pace.)


These organisational topics are important and there are dynamics here that the article doesn't emphasis on what and why this "Bureaucrat Mode" happens.

When companies are founded, there must be people involved who can execute a large chunk of the value chain single handily (if not the entire thing). Like a restauranteer who can buy ingredients, cook them, put together an interesting menu, engage in entertaining chit-chat, knows how to advertise and is good with finances.

In a large company though accountability matters a lot more and comparative advantage becomes a factor. It is also hard to hire great generalists (50% chance someone has a specific skill, that combination above is already approaching 1:100, let alone being good at something). So you specialise - there is a procurement specialist, a chef, a menu designer, a hostess, etc, etc.

Shortly after that transition there are still old hands around in leadership positions who know the entire value chain, but they slowly leave the business. Eventually there is a group of subject matter experts who execute the known chain really efficiently but no longer have personal or even institutional knowledge of how to set up a valuable new process because they specialise (theory of comparative advantage style logic kicks in). At this point, the dictatorial centralised nature of the company becomes a problem. If change is required, it depends on a tiny pool of leaders who are personally unclear on how the thing they control works at the micro level because they don't have the skillset required to set up new businesses. The only safe option is to iterate on the existing process, the company simply isn't capable of radical change any more. Or if it is, success will be more of a fluke than a predictable thing.


Try Enu

https://getenu.com/

Enu is a 3d live coding playground where you can control objects with code. Similar to LOGO but in 3d. It uses Nim - language very similar to Python and easy to pick up.

Duscussed previously on HN:

17 comments - https://news.ycombinator.com/item?id=36966116

6 comments - https://news.ycombinator.com/item?id=38520901

Nim forum post with announcement of Enu 0.2 and some useful links: https://forum.nim-lang.org/t/10700


My general take (and w/ the caveat that every system is different) is as follows:

- procedural code to enter into the system (and perhaps that's all you need)

- object oriented code for domain modeling

- functional code for data structure transformations & some light custom control flow implementation (but not too much)

I like the imperative shell, functional core pattern quite a bit, and focusing on data structures is great advice as well. The anti-OO trend in the industry has been richly earned by the OO architecture astronauts[1], but the idea of gathering a data structure and the operations on that data structure in a single place, with data hiding, is a good one, particularly for domain modeling.

In general I think we are maturing as an industry, recognizing that various approaches have their strengths and weaknesses and a good software engineer can mix and match them when building a successful software project.

There is no silver bullet. If only someone had told us that years ago!

[1] - https://www.joelonsoftware.com/2001/04/21/dont-let-architect...


The same artist has some excellent tutorials on how to implement a lot of those effects: https://bleuje.com/tutorials/

I've found expanding conversations with GPT-4 are most effective for building code snippets. Start with asking for the basic functionality and continue expanding the feature set. Here's an example of building a simple local frontend app to interface with the TTS API https://chat.openai.com/share/8ea1e3ea-0763-4118-8c83-a2f5ea...

A short explanation as to how this works:

The voice can be modeled using two main components. The vocal chords are a periodic source of sound, which is then filtered by the mouth and tongue to produce vowel sounds [0]. The filter can be modeled as a set of band-pass filters, each of which let through a specific band of frequencies — these are called ‘formants’ in acoustic phonetics. Different vowel sounds are produced by combining formants at different pitches in a systematic way [1]. You can hear this yourself by very slowly moving your mouth from saying an ‘eeeee’ sound to an ‘ooooo’ sound: if you listen carefully, you can hear one formant changing pitch while the others stay the same. (I like [2] as an intro to this kind of stuff.)

The ‘voder’ works by having one key for each possible frequency band-pass filter. Pressing multiple keys adds the resulting sounds, producing an output sound with distinct formants. If you use the right formants, the resulting sound is very similar to that produced by a human mouth saying a specific vowel! Software such as the vowel editor in Praat [3] take it further, by allowing selection of formants from a standard vowel chart.

[0] Consonantal sounds are a bit more complicated, since they tend to involve various different noise sources and transient disturbances of the sound. For instance, /ʃ/ (the ‘sh’ sound) is noise of a lower frequency than /s/. I can’t work out how Harper produced the difference between those two sounds in the video — it seems to be impossible to do this with the live demo. In fact, any sort of pitch control seems to be impossible in the demo.

[1] This is how overtone singing and throat singing works! Selectively amplifying one formant gives the impression that you’re singing that note as the same time as the ‘base’ pitch. In fact, if you do that, your vocal cords are producing a pitch plus all its overtones, while your mouth is enhancing one overtone while filtering out all the others.

[2] https://newt.phys.unsw.edu.au/jw/voice.html

[3] https://www.fon.hum.uva.nl/praat/ — probably also available from your favourite Linux distro!


Here's a similar project that was done awhile ago

https://github.com/qrdlgit/simbiotico


And another - https://www.youtube.com/watch?v=MIfhunAwZew

These folks have been working on this for quite awhile.


I'm using https://github.com/yt-dlp/yt-dlp to download my favorite videos, and after years of using it, its worth the effort. Many good memories would have been inaccessible otherwise.

I never did the SICP picture language exercises, but the book Concrete Abstractions* has some very similar exercises, but done through a simple library that outputs EPS.

* https://gustavus.edu/mcs/max/concrete-abstractions.html


National emerald isle. I've never looked to another rental company after experiencing it.

Sceptre is fantastic for this.

e.g. https://www.walmart.com/ip/Sceptre-55-Class-4K-UHD-LED-TV-HD...

Zero smart features, and all modern capabilities. It's also a TV, as opposed to a computer monitor, so it has the expected TV speakers and ports.


The best trombone you can play in your web browser is the pink trombone. https://dood.al/pinktrombone/

I have found that the best way of learning the HtDP approach to program design, at least for me (I find the book itself a bit dry), are the EdX "How to Code" free moocs [1] [2]. The instructor is fantastic. It completely changed the way I program and design.

If you like the approach and want to learn more, like, for instance, how to extend it to OO design, I list below links to several courses (most, except for the last one, offer enough material to complete them on your own, but I couldn't find any videos) at the university where HtDP's main author, Matthias Felleisen, is tenured (North Eastern). The courses are listed in the order in which they should be taken, and the rationale is explained by the professor in the paper "Developing Developers" [3]:

* CS 2500 - Fundamentals I [https://course.ccs.neu.edu/cs2500/]

* CS 2510 - Fundamentals II - Introduction to Class-based Program Design [https://course.ccs.neu.edu/cs2510/index.html]

* CS 2800 - Logic and Computation [https://course.ccs.neu.edu/cs2800/index.html]

* CS 3500 - Object Oriented Design - Spring 2018 (scaling up the 3 previous courses) [https://course.ccs.neu.edu/cs3500/]

* CS 4500 - Software Development [http://www.ccs.neu.edu/home/matthias/4500-f18/index.html]

[1] https://www.edx.org/course/how-code-simple-data-ubcx-htc1x

[2] https://www.edx.org/course/how-code-complex-data-ubcx-htc2x

[3] http://felleisen.org/matthias/Thoughts/Developing_Developers...


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

Search: