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

I've seen some issue with this approach is that management will want to sell the prototype, bypassing the "rewrite from the lesson learned" step, and then every shortcut took into the prototype will bite you, a lot..

And things like "race conditions"/lack of scalability due to improper threading architecture aren't especially easy to fix(!)..


The Anna Karenina principle looms large in software engineer projects. Basically there are an infinite failure modes that can occur due to small actions or wrong thinking by one or more influential people, but there is only one way to make large projects successful. Basically the team has to have sufficient expertise to cover the surface area, and those individuals need enough trust from leadership to navigate the million known and unknown pitfalls that await.

You don't ever make the prototype public.

Also, there's a certain point where you can't avoid management sabotaging things.


Sometimes you don't know what needs to be built until you build it. These end-to-end prototypes are how to enhance your understanding and develop deeper intuition about possibilities, where risks lie, etc.

It's a minor detail but list starting at 1, with -1 being the last élément and 0 being 'none' is weird.. Why did you make this choice instead of 0 for the first élément, -1 for the last one? It would avoid the 0 'trap'.

Not Tomo’s developer, but my position on the 1 vs. 0 for list-like object indexing goes like…

1) using 0 as the index of the first element in a list-like object ISA holdover from C (most of the earlier languages used either 1 based or flexible base for indexing);

2) in C, 0 is the index due to the manner of C’s array indexing implementation;

3) if holding onto the C semantics (or syntax in some respects) is not an explicit goal of the language, then flexible indexing should be the default (declared at creation point for the list-like object);

4) in flexible default is not appealing to the language designer, and again, maintaining C semantics is not a goal, then 1 based should be the next reasonable default.

For me, when counting things (and most other native English speakers, if not most people in general), the first item counted is object 1. Therefore, 1 should be the index of the beginning of the list-like objects indexing.

I’m not sure how about 0 being ‘None’, but I might find it intuitive if thinking more about it.



> Eventually both Windows and Linux programs moved to a model where the OS just gave you the window as a drawing surface, and you were supposed to fill it.

If you follow this model, how do you solve the accessibility issue?


>signed integer overflow being UB would count for C/C++

Then, I raise you to Zig which has unsigned integer overflow being UB.


Interestingly enough, Zig does not use the same terminology as C/C++/Rust do here. Zig has "illegal behavior," which is either "safety checked" or "unchecked." Unchecked illegal behavior is like undefined behavior. Compiler flags and in-source annotations can change the semantics from checked to unchecked or vice versa.

Anyway that's a long way of saying that you're right, integer overflow is illegal behavior, I just think it's interesting.


Rust has UB overflow as well, just unsafe.

https://doc.rust-lang.org/std/intrinsics/fn.unchecked_add.ht...


> Java everything is boxed anyway

Not true, there's int and Integer.


Right but you can’t use them as type arguments to Java’s generics so they’re not really relevant in this context.


> I noticed during my three week summer vacation that it took me a good week to unwind and slow down.

It depends a lot on what you do on your holiday. I think it's best to start with something "mind focussing": you're not going to think about your job while skydiving, scuba-diving etc.


For && and || I disagree: they are 'shortcircuiting' operators and as such they deserve a différent name than just 'and', 'or'. That said &| should have been named and,or which would have freed &| to use for the shortcircuit operators.


> The cost of dead people is a lot higher than the cost of developer time.

So you're using proof on every line of code you produce?


> So you're using proof on every line of code you produce?

No, except for trivially (the code is statically and strongly typed, which is a proof mechanism). The set of activities chosen to give confidence in defect rate is varied, but only a few of them would fit either a traditional or formal verification definition of a proof. See DO-178C for more.


Once Claude found a bug in my code but I had to explain the structure of the data. Then and only then it found the bug.


Error safe, the : or :: I kind of doubt it, I think that finding a typing mistake (two : instead of 1) won't be easy..


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

Search: