5 ms·

Ask HN: What technology do you regret choosing?

13 points by networked 5y ago

PinkPigeon 5y ago
For our website builder (https://pinkpigeon.co.uk https://pinkpigeon.co.uk) we once chose an ORM (GORM for Go specifically). In case you don't know what this does, it's an abstraction layer for working with databases like MySQL, PostgresQL, etc. Everyone warns against using them, but in the very early days of my learning Go, there was a tutorial that included this, so I just went with it. ORMs give you some advantages: Switching database drivers (aka, switching databases) is pretty easy. If it's supported by your ORM, you can then just switch to a different DB entirely. For the simplest of operations, like just writing stuff to your DB and then retrieving it again, they work a charm. Especially in Go, the ability to automatically marshal things into structs is a blessing. BUT, then you try to start doing things with many2many relationships, or retrieving sorted data in a very specific, nested query and things go sideways quickly. I ended up finding it much harder to try to figure out how to do some pretty obvious things. Endless hours on Stackoverflow fighting the ORM and its shockingly bad documentation... Eventually I just bit the bullet and learned how to write Postgres queries, along with a small Go library called sqlx (https://jmoiron.github.io/sqlx/ https://jmoiron.github.io/sqlx/) which massively outperformed GORM (https://medium.com/@rocketlaunchr.cloud/how-to-benchmark-dbq-vs-sqlx-vs-gorm-e814caacecb5 https://medium.com/@rocketlaunchr.cloud/how-to-benchmark-dbq...) and it's much more straight forward to reason about the relationship between my application layer and the DB.
mikewarot 5y ago
Python - I had side project, an Excel "database" that needed some graphs done in a much faster manner. I had been out of programming full time for about 20 years, and figured that Python with GUI builder would be the way to go. I had foolishly assumed that the tools had gotten better in the past 20 years. The last major programming I did was in Delphi under Windows XP, etc. I was dead wrong. I burned through two different GUI Builders each ending up with 20minute to 1 hour cycle times every time I changed a major GUI element. The base problem is that these tools don't allow two-way changes, they only create a python file to then use. I ended up creating a set of files that allowed me to decouple the generated python from my code, and it mostly worked. It was when I needed to change the type of control from a list to a combobox that everything broke. I had taken far too much of my free time learning and getting this to work. I tried out Lazarus (because Delphi is out of my price range), and it was good enough. I wasted the code. (In the same sense you waste a via of medicine once you've drawn the dose for the patient) In less than a week, I was back up and running, and changes were quick and easy to make. Python is good for some things, but a GUI isn't one of them. Charts that took 5 minutes in Excel now take a few seconds in Lazarus.
- PinkPigeon 5y ago
  https://kivy.org/#home https://kivy.org/#home is the closest I ever got to working with UI in Python and not hating it. But it still appears to be an unsolved problem.
ggm 5y ago
Gas cooker over induction in an off-the-plan new high modern concrete apartment building. Retrofit for high current turns out to be ruinously expensive. Imperative-dominant programming language. I think I'd be solving different problems if I had learned to think in functional mode.
- vanilla-almond 5y ago
  "Gas cooker over induction" If it hadn't being ruinously expensive, what were your reasons for preferring a gas cooker over induction? I have a gas cooker, but have used a induction stove a few times and liked it. The induction model I used was not as controllable as a gas flame, but I understand this can vary by brand or model. I see induction gaining popularity - it is supposedly more energy-efficient than gas, can cook some dishes more quickly (boiling water is fast), and is much easier to clean than a gas stovetop.
  - ggm 5y ago
    If it hadn't being ruinously expensive, what were your reasons for preferring a gas cooker over induction? We were ignorant of the post-build costs. If we had known the 10x exposure in costs to re-wire, we'd have paid up front for induction. We wanted Gas because of belief it was "better" for our style of cooking but gas cooking albiet responsive, is highly dependent on the heat energy the stovetop puts out, and the heat energy in the gas supply (pressure) And we kind of missed out on both: a brand name stovetop is disappointingly "slow" even on the wok burner, and our supply pressure is on the low side of normal. If you have Aluminium or mixed origin cookware Induction usually demands new pans because they must be responsive to induction current. We didn't want to replace a bunch of (to us expensive) cookware. We're now much more aware and buy induction capable replacements, although quite why I don't know: we're not moving, and as this thread says, the retrofit cost for induction is not good. Induction comes with it's own problems: It's surprisingly noisy, you need to cool those magnetic coils, its bulky under the workbench, and you don't want to put people with pacemakers on your cooktop, no matter now much you might want to experiment. The cleaning is a huge thing. I do the stovetop, I've used more barkeepers friend in the last year than the proceeding 20 from fat spatter baking on. You can wipe down an induction very quickly after cooking ends. Ideally? I'd have argued for two gas rings, and a square of induction. Wok gotta wok.
nickx720 5y ago
Nothing against Angular 2+ ,but I have had a horrid experience with the complexity of the framework. I do admit it was mostly my fault since I went into it blind, but coming from a more jquery/(copy paste and hope it works) mindset, I just didn't really pick up the various nuances of the framework. But I was lucky enough to work in a different project which had React, and it somehow felt more natural to my brain (more JavaScripty I suppose). I have played around even with Svelte and other frameworks as well, but to me personally Angular always stood out as the worst. By no means my personal view on the framework dimnishes its usefulness and I know a lot of people who prefer Angular. But for me personally it wasn't the best choice.
muzani 5y ago
It's often been the low-code ones. From Multimedia Fusion to Bootstrap Studio. Many come with undocumented bugs or limitations, like loops failing or not being able to do a certain thing. Bootstrap Studio ended up being training wheels to responsive web dev for me. On the "higher" code stuff, Android is chock full of anti-patterns. Adopting the full repository flow of Android, from web to local database cache will lock you in a lot of patterns. You have to design your data into a way that's easily stored in SQLite, i.e. be pretty damn clear whether your data is an int, string, or pointer, which is hard to tell with new features. And then there's the mess of testing this. Some of these features are still in alpha, e.g. an official library might support pages in the form of integers, but not Strings. So for the most part, you rarely ever want to code Android in the manner that Google teaches you to, unless you're in a company with 10 devs on a team or something.
thorin 5y ago
It wasn't my choice (when does the technologist get to choose), but here is a short list: * Silverlight (!) * Adobe Air (about 2 weeks before it was end dated) * Rhomobile (native multi-platform mobile build, seemed like a good idea at the time...) * Microsoft Service Fabric
lmarcos 5y ago
Goa (https://github.com/goadesign/goa https://github.com/goadesign/goa). Having to maintain autogenerated code is worse than to maintain "your own" code.

13 points by networked 5y ago

For our website builder (https://pinkpigeon.co.uk https://pinkpigeon.co.uk) we once chose an ORM (GORM for Go specifically). In case you don't know what this does, it's an abstraction layer for working with databases like MySQL, PostgresQL, etc. Everyone warns against using them, but in the very early days of my learning Go, there was a tutorial that included this, so I just went with it. ORMs give you some advantages: Switching database drivers (aka, switching databases) is pretty easy. If it's supported by your ORM, you can then just switch to a different DB entirely. For the simplest of operations, like just writing stuff to your DB and then retrieving it again, they work a charm. Especially in Go, the ability to automatically marshal things into structs is a blessing. BUT, then you try to start doing things with many2many relationships, or retrieving sorted data in a very specific, nested query and things go sideways quickly. I ended up finding it much harder to try to figure out how to do some pretty obvious things. Endless hours on Stackoverflow fighting the ORM and its shockingly bad documentation... Eventually I just bit the bullet and learned how to write Postgres queries, along with a small Go library called sqlx (https://jmoiron.github.io/sqlx/ https://jmoiron.github.io/sqlx/) which massively outperformed GORM (https://medium.com/@rocketlaunchr.cloud/how-to-benchmark-dbq-vs-sqlx-vs-gorm-e814caacecb5 https://medium.com/@rocketlaunchr.cloud/how-to-benchmark-dbq...) and it's much more straight forward to reason about the relationship between my application layer and the DB.

mikewarot 5y ago

Python - I had side project, an Excel "database" that needed some graphs done in a much faster manner. I had been out of programming full time for about 20 years, and figured that Python with GUI builder would be the way to go. I had foolishly assumed that the tools had gotten better in the past 20 years. The last major programming I did was in Delphi under Windows XP, etc. I was dead wrong. I burned through two different GUI Builders each ending up with 20minute to 1 hour cycle times every time I changed a major GUI element. The base problem is that these tools don't allow two-way changes, they only create a python file to then use. I ended up creating a set of files that allowed me to decouple the generated python from my code, and it mostly worked. It was when I needed to change the type of control from a list to a combobox that everything broke. I had taken far too much of my free time learning and getting this to work. I tried out Lazarus (because Delphi is out of my price range), and it was good enough. I wasted the code. (In the same sense you waste a via of medicine once you've drawn the dose for the patient) In less than a week, I was back up and running, and changes were quick and easy to make. Python is good for some things, but a GUI isn't one of them. Charts that took 5 minutes in Excel now take a few seconds in Lazarus.

PinkPigeon 5y ago
https://kivy.org/#home https://kivy.org/#home is the closest I ever got to working with UI in Python and not hating it. But it still appears to be an unsolved problem.

ggm 5y ago

Gas cooker over induction in an off-the-plan new high modern concrete apartment building. Retrofit for high current turns out to be ruinously expensive. Imperative-dominant programming language. I think I'd be solving different problems if I had learned to think in functional mode.

vanilla-almond 5y ago
"Gas cooker over induction" If it hadn't being ruinously expensive, what were your reasons for preferring a gas cooker over induction? I have a gas cooker, but have used a induction stove a few times and liked it. The induction model I used was not as controllable as a gas flame, but I understand this can vary by brand or model. I see induction gaining popularity - it is supposedly more energy-efficient than gas, can cook some dishes more quickly (boiling water is fast), and is much easier to clean than a gas stovetop.
- ggm 5y ago
  If it hadn't being ruinously expensive, what were your reasons for preferring a gas cooker over induction? We were ignorant of the post-build costs. If we had known the 10x exposure in costs to re-wire, we'd have paid up front for induction. We wanted Gas because of belief it was "better" for our style of cooking but gas cooking albiet responsive, is highly dependent on the heat energy the stovetop puts out, and the heat energy in the gas supply (pressure) And we kind of missed out on both: a brand name stovetop is disappointingly "slow" even on the wok burner, and our supply pressure is on the low side of normal. If you have Aluminium or mixed origin cookware Induction usually demands new pans because they must be responsive to induction current. We didn't want to replace a bunch of (to us expensive) cookware. We're now much more aware and buy induction capable replacements, although quite why I don't know: we're not moving, and as this thread says, the retrofit cost for induction is not good. Induction comes with it's own problems: It's surprisingly noisy, you need to cool those magnetic coils, its bulky under the workbench, and you don't want to put people with pacemakers on your cooktop, no matter now much you might want to experiment. The cleaning is a huge thing. I do the stovetop, I've used more barkeepers friend in the last year than the proceeding 20 from fat spatter baking on. You can wipe down an induction very quickly after cooking ends. Ideally? I'd have argued for two gas rings, and a square of induction. Wok gotta wok.

nickx720 5y ago

Nothing against Angular 2+ ,but I have had a horrid experience with the complexity of the framework. I do admit it was mostly my fault since I went into it blind, but coming from a more jquery/(copy paste and hope it works) mindset, I just didn't really pick up the various nuances of the framework. But I was lucky enough to work in a different project which had React, and it somehow felt more natural to my brain (more JavaScripty I suppose). I have played around even with Svelte and other frameworks as well, but to me personally Angular always stood out as the worst. By no means my personal view on the framework dimnishes its usefulness and I know a lot of people who prefer Angular. But for me personally it wasn't the best choice.

muzani 5y ago

It's often been the low-code ones. From Multimedia Fusion to Bootstrap Studio. Many come with undocumented bugs or limitations, like loops failing or not being able to do a certain thing. Bootstrap Studio ended up being training wheels to responsive web dev for me. On the "higher" code stuff, Android is chock full of anti-patterns. Adopting the full repository flow of Android, from web to local database cache will lock you in a lot of patterns. You have to design your data into a way that's easily stored in SQLite, i.e. be pretty damn clear whether your data is an int, string, or pointer, which is hard to tell with new features. And then there's the mess of testing this. Some of these features are still in alpha, e.g. an official library might support pages in the form of integers, but not Strings. So for the most part, you rarely ever want to code Android in the manner that Google teaches you to, unless you're in a company with 10 devs on a team or something.

thorin 5y ago

It wasn't my choice (when does the technologist get to choose), but here is a short list: * Silverlight (!) * Adobe Air (about 2 weeks before it was end dated) * Rhomobile (native multi-platform mobile build, seemed like a good idea at the time...) * Microsoft Service Fabric

lmarcos 5y ago

Goa (https://github.com/goadesign/goa https://github.com/goadesign/goa). Having to maintain autogenerated code is worse than to maintain "your own" code.