4 ms·

> us programmers are worried we will be accused of being users if we use tools that are interactive. [...] Of course programmers do not realize this psychologic

by yepguy 8y ago

> us programmers are worried we will be accused of being users if we use tools that are interactive. [...] Of course programmers do not realize this psychological issue exists and will not admit it is a possibility. It would be nice if you explained what you even mean by this instead of just claiming that programmers who don't agree are in denial. What programmer is embarrassed to also be a user? And programmers use interactive tools all time. REPLs, debuggers, editors, GUI design tools, and live-reloading web servers all qualify in my book.

nikofeyn 8y ago
if you need any example of this type of behavior just look how "normal programmers" view labview programmers. most people completely snub their nose at labview "users" for not being real programmers and engineers (don't tell me they don't because i experience this constantly). in addition, labview's capability is often misunderstood by people who hide behind a wall of self-imposed bias. many times people are actually unaware of what is possible with labview simply because they don't care to know because it's not the real, hardcore, in the weeds type of stuff they were taught in school. meanwhile, people using labview to program windows, real-time high-performance, real-time embedded linux, and fpga systems (including cameras, sdr, etc.), all with the same language, are able to accomplish quite a lot. i fully concede that labview has many downfalls, but my criticism is based upon actual use of the language and tools and not via some uninformed bias. because of that, my criticisms don't necessarily overlap with those of the uninformed. and this is all relevant because when i tell people i use labview, you can just see any interest in my programming work leave their face, as i've become a simple tool user in their eyes. this is a specific example regarding labview, but these types of biases exist everywhere, where engineers blind themselves to what is possible by the opacity of what was possible.
yepguy 8y ago
Also keep in mind that when you stack abstractions on top of each other, the whole stack gets more brittle. So if you want me to use your better idea, it shouldn't abstract over the thing you're trying to replace. To give an example: if you want to replace hierarchical filesystems you shouldn't build a thing that hides them from me, you should build a thing that doesn't use them at all. (This isn't a hard rule, sometimes exceptions are worth the trade-off.) Understandably, this means changing things is a LOT more work than you're probably prepared for. Don't assume that we're only stuck in the past for bad reasons.

by yepguy 8y ago

nikofeyn 8y ago

if you need any example of this type of behavior just look how "normal programmers" view labview programmers. most people completely snub their nose at labview "users" for not being real programmers and engineers (don't tell me they don't because i experience this constantly). in addition, labview's capability is often misunderstood by people who hide behind a wall of self-imposed bias. many times people are actually unaware of what is possible with labview simply because they don't care to know because it's not the real, hardcore, in the weeds type of stuff they were taught in school. meanwhile, people using labview to program windows, real-time high-performance, real-time embedded linux, and fpga systems (including cameras, sdr, etc.), all with the same language, are able to accomplish quite a lot. i fully concede that labview has many downfalls, but my criticism is based upon actual use of the language and tools and not via some uninformed bias. because of that, my criticisms don't necessarily overlap with those of the uninformed. and this is all relevant because when i tell people i use labview, you can just see any interest in my programming work leave their face, as i've become a simple tool user in their eyes. this is a specific example regarding labview, but these types of biases exist everywhere, where engineers blind themselves to what is possible by the opacity of what was possible.

yepguy 8y ago

Also keep in mind that when you stack abstractions on top of each other, the whole stack gets more brittle. So if you want me to use your better idea, it shouldn't abstract over the thing you're trying to replace. To give an example: if you want to replace hierarchical filesystems you shouldn't build a thing that hides them from me, you should build a thing that doesn't use them at all. (This isn't a hard rule, sometimes exceptions are worth the trade-off.) Understandably, this means changing things is a LOT more work than you're probably prepared for. Don't assume that we're only stuck in the past for bad reasons.