Hacker News .hnnew | past | comments | ask | show | jobs | submit | NoWizards's commentslogin

When you do it this way isn't even a framework is just a helper library (at his best). There is another concept for this kind of micro-libraries but calling "framework" to something that will not establish a frame of work for you.


I have seen this happen before my eyes: When i was young (~17 y.o) i was able to remember all my family IDs, my friends phone numbers and a lot of data about them. Now i rely a lot on my smartphone to tell me their phone numbers, their birthdays, their address, etc... (Sadly today i dont even know the phone number of my gf, out of pure laziness). As i have become more and more lazy and let the tools do their job i'm losing my own skills on it "because i need my brain for bigger things - sure".


missing another opportunity when she says she likes Aaron Samuels and girls consensus says NO, she cant


Just remember: Dev works in mysterious ways.


Its more like the time to become interactive. Even if internet and smarphones are fast. Sometimes it's pretty annoying to click an unresponsive page... just because it's loading-starting a lot of js


came here to add some similar feedback. while all aren't necessary, giving a visual clue when you get a correct and wrong answer its


Is there a (mathematical if possible) way, using FSMs, to demonstrate if a specific case or behavior can or can't be implemented.


Yes there is. You may want to look into Deterministic and Non-Deterministic Finite Automata. They are foundational to computability and Turing machines.

https://en.wikipedia.org/wiki/Deterministic_finite_automaton...


You are designing a "prefix code". It is a collection of strings of button presses such as {A, BA, BBAA, BBABA, BBB, ...}. Each string maps to an action.

Ideally no string is a prefix of another string. Even more ideally any infinite sequence of As and Bs can be decoded into a sequence of actions.


I couldn't disagree more with you... All i see when working with different levels of experienced contributors is param:any any[]. Even more when you want to interact directly with DOM instead of using an opinionated framework.


You‘re blaming the active misuse of a tool on the tool itself.


This is why "no-explicit-any" should be enforced in every project.

https://github.com/typescript-eslint/typescript-eslint/blob/...


This is either just code that is too complicated or devs that aren't doing a good job of type hinting.

Everytime there is an any, it means that each developer reading or modifying this code has to find it out for themselves - every single time. Why not just type hint it correctly in the first place.


I'm one of those `any` developers, and can attest to the first scenario. Had a client ask me to fix a bug in a repo that I wasn't familiar with. I spin it up, start looking through the code, and it's this massively over-engineered beast. 27K lines of Angular code to support a 2 page SPA that's basically just a note taking app.

Anyways, it's TS, and I don't know TS but I know how typing works so I can make my way around. I need to alter an interface to fix the bug, but with all the code it's very difficult to tell whether the change will break something either in the compiler or at runtime. To add on top of all that, the client needed the change to go out that day.

So guess what's going to happen? I'm using fucking `any` and I don't care.

Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.


> Anyways, it's TS, and I don't know TS but I know how typing works so I can make my way around. I need to alter an interface to fix the bug, but with all the code it's very difficult to tell whether the change will break something either in the compiler or at runtime. To add on top of all that, the client needed the change to go out that day.

It is massively easier to make change to large TS codebase. Just because you never bothered to learn TS and you rush feature at cost to maintenance, do not mean it is TS fault.

> Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.

Because native types would create even more fragmentation while being less powerful than TS. JS was never intended for application development, we either embrace compilers or move away from language that have pathetic standard library, dynamic and complex type coercion rules, no stable module system, lack of strong leadership and legacy of supporting IE.


Not sure, our reproductive system is pretty sensible to radiation... we won't be wiped instantly but in a few generations we can get extint.


Every day is less impressive to create an entire product by one self, the ammount of tools created to simplify or automate common tasks give us a lot of work done.


But the expectations rise too.


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

Search: