Software is stupid, programmers are overpaid poets.  - Page 1
Forum section: electronics / general

author: dryjoints
author_rank: Regular Contributor
timestamp: January 21, 2018, 06:20:12 am
content: ... well that's what I think. Now read this:https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/Get ready for self-crashing cars & self-employing robots.

author: Brumby
author_rank: Unknown
timestamp: January 21, 2018, 06:46:01 am
content: The programmer(s) were certainly the creator of the problem - but the responsibility lays with whoever signed it off as "production ready".I could go on about systems design, review, coding, testing, etc.... but I won't - or I'll be here all week.

author: Richard Crowley
author_rank: Super Contributor
timestamp: January 21, 2018, 06:47:45 am
content: Welcome to the 20th century (and beyond).Electrocution was unknown until the 20th century.Just another cost of doing business in the modern age.

author: HalFET
author_rank: Frequent Contributor
timestamp: January 21, 2018, 07:45:08 am
content: Could have been solved if they had only done more unit testing, added more abstraction layers, and introduced that fancy new framework!

author: Brumby
author_rank: Unknown
timestamp: January 21, 2018, 07:54:40 am
content: ...or they could have asked someone how many calls come in - rather than using a blind guess.

author: dmills
author_rank: Super Contributor
timestamp: January 21, 2018, 09:00:16 am
content: Quote from: HalFET on January 21, 2018, 07:45:08 amAh, you work with "web programmers" too.Funny how the frigging web site on an embedded device ends up using more code space then the program that does whatever the thing was really intended to do (And how when you point out that the result needs an I7 with modern gamer graphics to render properly, they cannot explain where the time goes).Regards, Dan.

author: Berni
author_rank: Super Contributor
timestamp: January 21, 2018, 09:02:06 am
content: Quote from: HalFET on January 21, 2018, 07:45:08 amThat is exactly why i don't like where programing is going these days.Everything is buried under so many layers that nobody really even understands exactly what is going on anymore and then something you did at the top layer causes something unexpected to happen 4 layers down the software stack. The usual way to fix such a bug is to just try doing the thing in a slightly different way and see if the issue disappears.EDIT: Oh and yes how the thing now suddenly needs 60MB of RAM to run on some small embedded system because of all the junk the lower layers are hauling with it and certain operations in the top layer are so slow that they start affecting the UI responsiveness even tho there is a big ass multicore 2GHz ARM CPU running it all

author: dmills
author_rank: Super Contributor
timestamp: January 21, 2018, 09:31:14 am
content: Oh yes, the PC (And Web) programmers view that RAM is infinite, and that only crashing once a month is reliable.I also love that javascript (Spit!) does not let you do proper networking, in particular it seems you cannot listen to a UDP port, and multicast is 'interesting' very annoying when you have something like audio metering data that you want on a devices web page. Would generating arbitrary TCP packets really have been too much to ask?Everyone should start by being required to write "Elite" on an 8 bit 1MHz 6502 with 48kB of RAM (Including the frame buffer).Regards, Dan.

author: llkiwi2006
author_rank: Regular Contributor
timestamp: January 21, 2018, 09:44:25 am
content: Quote from: Berni on January 21, 2018, 09:02:06 amHow is that a problem? Often the first step to locating a bug is when it occurs and what changes will cause it to not occur. There are people who understand the lower layers, so communicate with them and they will help you with your issue. Isn't it the same thing true in hardware? Do you understand the design decisions in an ic that might be causing you problems?Although I do agree there is too much complexity and abstractions quite a lot of software, especially things using "web technologies" (looking at you electron).

author: llkiwi2006
author_rank: Regular Contributor
timestamp: January 21, 2018, 09:47:34 am
content: Quote from: dmills on January 21, 2018, 09:31:14 amHey crashing for 45 minutes every month is still 99.9% reliability. /s

author: dmills
author_rank: Super Contributor
timestamp: January 21, 2018, 09:53:37 am
content: Quote from: llkiwi2006 on January 21, 2018, 09:47:34 amQuite!Regards, Dan.

author: Rerouter
author_rank: Super Contributor
timestamp: January 21, 2018, 10:00:24 am
content: Ok, this seems like a dumb question, but if the TLA+ they keep praising fixes many fundamental issues, and they seem to imply it is only acceptance by programmers that is preventing it wider access.Why is it a java backbone,And if I had to climb the hill that would be using Eclipse IDE, could TLA+ toolbox be used with something like an embedded micro controller, spitting out firmware, or is this locked away to the likes of computer programming,

author: Berni
author_rank: Super Contributor
timestamp: January 21, 2018, 10:30:07 am
content: Quote from: llkiwi2006 on January 21, 2018, 09:44:25 amYes but i mean the nonsense bugs that you have no idea why they happen and the documentation doesn't say anything about it and the layers underneath are not in your control.For example i had a case where i was using the .NET chart control in C# and came across a bug where the whole program would suddenly crash inside of the paint calls to the controls. The debugger doesn't really give you any details where it happened, just tells you what form window the event handler crashed on, but i knew it was the chart controls fault as it only happened when i did stuff to it. If it had the source code for that control then it would likely point you into it and where the crash happened. Normally the this chart control has some safeguards inside it that draw a big red X mark across the control when it gets too confused or misconfigured to draw something reasonable. Well they forgot to safeguard against this overflow that happens if your charts Y axis has values above about 1 million and you zoom into a small part of the chart. Okay so then il just wrap a error handler around it to catch it so that my program doesn't crash on the spot but just shows an error text or something. Well... the mechanism that calls events is deeper down in .NET so i can't just wrap a Try statement around it, nor can i wrap the code that's causing it in a Try statement since i don't have the source code to the chart control. Consulting the documentation says that it should display a red X when it encounters an error. Don't think anyone at microsoft would be willing to help me with the problem, but if enough people complain they will probably fix it in the next version of the .NET Framework.I guess it is a bit similar in hardware, but the layers underneath tend to be simpler than these massive software stacks that modern code runs on. So its easier to properly document them and debug them. Tho when writing hardware drivers i do run into cases where something is just plain broken. For example on TIs OMAP processors the SD card controllers buffer full flag was always zero, it supposedly worked for DMA transfers but manually reading it doesn't. The fault was not yet documented in the PDFs but the solution was to instead wait for the buffer empty flag(that worked fine) and fill the buffer with how ever many bytes the buffer is supposed to be able to hold.

author: janoc
author_rank: Super Contributor
timestamp: January 21, 2018, 01:28:44 pm
content: Quote from: dmills on January 21, 2018, 09:31:14 amYes, it would be a serious problem. Javascript in a browser is designed to run in a sandbox, if you let it open arbitrary network connections and generate random packets, you will have the largest DDOS botnet in the world - just pay a few bucks to an ad network to deliver your code as ads on some high profile websites.And this is not a theoretical attack - it has been done. There are websites that abuse your browser for cryptocurrency mining, for DDOS, etc.Before you complain about such limitation, try to think a bit outside of your problem "box" why that limitation is actually there.If you are writing stuff like that in Javascript, you are most likely doing it wrong.

author: chris_leyson
author_rank: Super Contributor
timestamp: January 21, 2018, 02:31:18 pm
content: QuoteI think some hardware is starting to go that way, one example is control loops in SMPS controllers. The traditional analogue opamps and comparators are being replaced by digital control loops so you can't use traditional control theory anymore to model you power supply. The digital control loops aren't even properly documented so they just become some abstract hidden layer of hardware which you end up having to second guess. Power Integrations and Dialog Semiconductor are just two companies I can think of with ON Semi and maybe TI working on similar designs. To be fair Dialog Semi at least give you a simulator.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 21, 2018, 03:33:26 pm
content: UncleBob Expecting Professionalism (Kuppelsalen, Copenhagen)Watch 1:07:37 to 1:12:45-ish. And maybe the rest of it as well.Uncle Bob: "Half the programmers in the world have less than 5 years experience."

author: dmills
author_rank: Super Contributor
timestamp: January 21, 2018, 04:00:45 pm
content: Quote from: janoc on January 21, 2018, 01:28:44 pmThat surely is what firewall rules exist to prevent?End of the day I don't really care what the JS does within its sandbox, but there are more appropriate places to filter network frames then at the edge of the sandbox, and those places are generally more usefully configurable.I would get less annoyed by this sort of thing if I was not always being told by our web devs that web based 'apps' were the future, when they clearly cannot do basic things that I would expect of a general purpose machine.regards, Dan.

author: dryjoints
author_rank: Regular Contributor
timestamp: January 21, 2018, 04:39:08 pm
content: Additionally, I find the term "programmer" to be somewhat of an ego massage, considering how many layers of software goop are underneath the layer that the "programmer" is copy/pasting templates into; unlike ASM, I very much doubt, if not almost GUARANTEE, that the "programmer" doesn't know, and never did know, the ASM instructions for the silicon upon which those many layers of software goop are piled.Then, we have the hilarity that is some of them calling themselves"SoftwareEngineers"

author: lundmar
author_rank: Frequent Contributor
timestamp: January 21, 2018, 04:55:51 pm
content: http://programming-motherfucker.com

author: Vtile
author_rank: Super Contributor
timestamp: January 21, 2018, 05:27:34 pm
content: There should be more serious use of coding languages like Grafcet seriously, instead of C derivatives or even Wirthian lingos..

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 21, 2018, 05:36:10 pm
content: Quote from: dmills on January 21, 2018, 09:31:14 amYou're confusing Javascript and the DOM, it's a common mistake. And imagine if any web page could arbitrarily generate any TCP packets it wanted... as in freely mess with your network.

author: bd139
author_rank: Super Contributor
timestamp: January 21, 2018, 05:40:55 pm
content: I’m not a programmer, I’m a unicorn shit shoveller.Realityhttps://www.stilldrinking.org/programming-sucks

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 21, 2018, 05:45:42 pm
content: Quote from: dmills on January 21, 2018, 04:00:45 pmYes, you can do that 100% in javascript, but don't expect the browser to do it because a browser is designed to run programs coming from any web page you visit and therefore must have severe privilege limitations. Many apps are written in .js and can do anything you want without the limitations of a browser, because they don't run in a browser.

author: tggzzz
author_rank: Super Contributor
timestamp: January 21, 2018, 05:59:09 pm
content: Quote from: dryjoints on January 21, 2018, 04:39:08 pmI'd be content if they could give a very roughpseudocodeexplanation of what happens during a function call.

author: Kjelt
author_rank: Super Contributor
timestamp: January 21, 2018, 06:02:38 pm
content: Being on both sides of the fence the biggest problem is that both disciplines do not cooperate more with eachother. It is not or the HW eng or the SW eng fault if problems arise, stop blaming eachother and take a look in each others kitchen before starting bitchin.SW has become massive the last decade. Many HW eng's have no clue how many locs are written and that it is virtually impossible to prevent all possible conditions, test all forks and all possible outcomes.Very expensive software, tests the code and tries to find all unhandled situations and reports issues.We once had five sw engineers work three months to get rid of all the possible issues that came from two months coding, it can be that complex.than most modern code use open source third party stacks what is in those, or do you think those are perfect? Do they really behave as documented under all conditions. Can they handle gracefully all input parameters?When I started 20+ years ago we had 3x more HW engineers than emb. SW engineers, we now have 20x more SW engineers than HW engineers, do you really think that is because the Company does not care? Or does it want all the latest and greatest "features" that clients can think of in their product?

author: Vtile
author_rank: Super Contributor
timestamp: January 21, 2018, 06:49:50 pm
content: Quote from: Kjelt on January 21, 2018, 06:02:38 pmThis or that, but the situation is shit.

author: Kjelt
author_rank: Super Contributor
timestamp: January 21, 2018, 07:41:24 pm
content: Quote from: Vtile on January 21, 2018, 06:49:50 pmThanks for that elaborate analysis and insight.Hardware also failshttps://www.eevblog.com/forum/projects/lots-of-failing-outdoor-led-lamps-very-long-overhead-mains-cable/and people are demanding quick release of apps and features.Takeaway everyones smartphone, kill Linux, OSX and Windows and lets all stop using computers because they have bugs.Lets face it life is not perfect and if society does not tune down on speed of progress this will only become worse also on the hardware side where the customer will be the tester.

author: vodka
author_rank: Frequent Contributor
timestamp: January 21, 2018, 07:46:43 pm
content: Quote from: Berni on January 21, 2018, 10:30:07 amI know .NET documentation is a shithole. You lost many time searching among class, methods ,etc. I yearn the old programming reference minibook that had my father: all the function of the language, fast for searching and very clean.You have many valor for using the .NET debugger, it is very messy. When i tired to see the .NET debugger, i usually use messagebox for debugging the source: more faster and less time.

author: filssavi
author_rank: Frequent Contributor
timestamp: January 21, 2018, 08:03:03 pm
content: The problem Is not software itself, but the ship barely functioning maybe beta (sometimes alpha) builds to the customers using them as guinea pigs and then patch it later as bug reports arrives because hiring a bunch of people to test shit and find bugs is much more expensive than a half assed PR blogpost when shit inevitably hits the fan...the biggest difference between HW and SW is that releasing a software patch is free meanwhile releasing a hardware patch (recalling a faulty product) is insanely expensive (just ask volkswagen), do you want peoples shipping quality software start imposing heavy fines and taxes on patchs and bugfix releases and see how the whole industry will focus on quality

author: vodka
author_rank: Frequent Contributor
timestamp: January 21, 2018, 09:03:15 pm
content: Quote from: filssavi on January 21, 2018, 08:03:03 pmThe great trouble that has the software is the quantity of lines of code, many are useless. Adding the programming paradigm POO and the efficient like JAVA for print a line by screen ,it needs four lines of source. Now , you imagine a complex system like SAP. Who is the brave that will debugger for seeking the fail and correct it?Economically, debugging is expensive on money and time, more easier is doing a new function and patch the error when it is produced, but against the size the program grow and it will spend more resources.An other thing , patching is more cheaper than other options but never free, less that the corporations pay the programmers with a rice bowls.

author: Len
author_rank: Frequent Contributor
timestamp: January 21, 2018, 09:12:17 pm
content: Quote from: dryjoints on January 21, 2018, 06:20:12 amThank you for explaining my profession to me, dryjoints. Now please tell us what you do for a living, so I can explain to everyone how stupid and incompetent YOU are.

author: llkiwi2006
author_rank: Regular Contributor
timestamp: January 21, 2018, 09:13:52 pm
content: Quote from: Berni on January 21, 2018, 10:30:07 am.NETI guess I had more luck with open source stuff. The one time I came across a compiler bug (in GHC, a Haskell compiler), people on the bug tracker helped me debug it and fixed it quite quickly.

author: VK5RC
author_rank: Unknown
timestamp: January 21, 2018, 09:26:45 pm
content: Read the book, The Stupidity Paradox: 'group think', peer pressure, thinking only in your little area, all have great potential for cock ups. With 'interconnectedness - the ability to spread this is fantastic!

author: filssavi
author_rank: Frequent Contributor
timestamp: January 21, 2018, 09:37:19 pm
content: Quote from: vodka on January 21, 2018, 09:03:15 pmDon’t take it personally on I am about to write... butThat is bullshit, there is plenty of mission critical software running aircrafts, nuclear power plants ans so on that being held at much higher standard and while it might not be 100% big free I never heard a nuclear meltdown due to a buffer overflow...Now I’m not saying that Microsoft office should be held to the same standards but there shuld be a middle groundAnd the argument about the lines of code is also shit, I can buy that for some crazy security vulnerabilities researchers find using deep knowledge of the whole stackBut let’a face it the 99.9% of the bugs are the same types we used to write in the ‘80 it’s 40 years ago...

author: Vtile
author_rank: Super Contributor
timestamp: January 21, 2018, 09:53:29 pm
content: Quote from: Kjelt on January 21, 2018, 07:41:24 pmSorry, I didn't attack against you, the opposite. The problem of overly complex SW creeping everywhere is just irritating. Reality, but still really irritating. Kind of like someone sell you a chainsaw with feature creep, but when you start to work with it you notice that the motor only runs 5 minutes. That would be essentially a worthless equipment. That said I have had two chainsaws, which have 0% of software, one had major design flaw in carburetor (german) and another had oilpump that did work only when rotated backwards (swedish). Needless to say they were the bottom of the lineup models, as I need one once in a year, still I would assume that chainsaw do have motor and pumps that runs.

author: Freelander
author_rank: Regular Contributor
timestamp: January 21, 2018, 10:24:50 pm
content: Quote from: dmills on January 21, 2018, 09:31:14 amHi Dan,Unless I am mistaken, (Quite possibly), then Elite was written with 32K ramincludingvideo ram. Wasn't the 'frame buffer' (Shadow) only on the post model A / B units ?Elite was introduced on the Model B (cassette) without the shadow ram afaik.

author: HalFET
author_rank: Frequent Contributor
timestamp: January 21, 2018, 10:40:19 pm
content: Quote from: dmills on January 21, 2018, 09:00:16 amYeah, you also really notice it on mobile phones. They become slower every year because they add more and more abstraction layers and bloated code in between. I'd say Android is a prime example of how to not build mobile software.

author: Marco
author_rank: Super Contributor
timestamp: January 21, 2018, 11:37:32 pm
content: The 911 one is just government stupidity and byzantine contracting. If they had an operation centre with operators knowledgeable about all their systems they would have switched over manually within a minute even with the completely bullshit absence of an automated alarm (they should have an independent program running to check whether calls are routed, and on top of that simply no call being routed for a couple of seconds should trip a sanity check for a human to check things out).

author: MT
author_rank: Super Contributor
timestamp: January 22, 2018, 01:23:07 am
content: Quote from: dryjoints on January 21, 2018, 06:20:12 amwould you consider ST generated HAL based code a contributor to future disasters?

author: Berni
author_rank: Super Contributor
timestamp: January 22, 2018, 06:33:32 am
content: Quote from: HalFET on January 21, 2018, 10:40:19 pmMicrosoft actually set a good example of a mobile OS here.They made a derivative of Windows CE called Windows mobile. Graphically it did kinda remind of Win 98 but it would run perfectly snappy even on 32MB of RAM and a old 200MHz ARM CPU with terrible MIPS/MHz. Did take forever to boot and did sometimes need a reboot every month or so but when it worked it worked great. Native exe programs ran with full performance while it did get support for all the other platforms from back in the day such as Java, .NET, Flash etc. It could do everything. Even included hardware 2D graphics with support for hardware video decode that could allow it to play every popular video format without dropping a frame back when being able to play a mp3 was a selling point of most other phones.Then the first iPhone was released and Android steam rolled the smartphone market. This made Microsoft panic and dump it to bring out Windows Phone 7 instead. This broke all backwards compatibility as it was a brand new product that is designed to be similar to Android with all the graphical eye candy and bloated features that bring modern much faster ARM CPUs down to a crawl.

author: ivaylo
author_rank: Frequent Contributor
timestamp: January 22, 2018, 08:07:32 am
content: Quote from: Kjelt on January 21, 2018, 06:02:38 pmThis! Was the latest Spectre vulnerability a hardware or a software f-up? Not passing judgment, asking. With modern devops, micro services, etc. complexity can be handled nicely in the web world actually (few people bother to learn though).

author: Berni
author_rank: Super Contributor
timestamp: January 22, 2018, 08:57:32 am
content: Quote from: MT on January 22, 2018, 01:23:07 amI had the pleasure to use STs HAL library and yes its horrible.For example the I2C driver is not capable of making a I2C bus restart sequence!It just does a stop followed by a start instead of real restart. According to the I2C spec this is wrong but 90% of I2C chips still work if you do this while some chips don't. To make things worse the way the HAL library uses the I2C controller means that it wont handle a restart being injected in the middle of the read sequence. As a result to get it to talk to my chip i had to rewrite the entire i2c read and i2c write functions by directly manipulating registers like it used to be in the old days.It would have taken me less time to write the damn I2C driver from scratch than it has taken me to figure out the HAL library, do stuff with it, debug why my chip is not talking to me, googling ways to make it do the correct i2c read seqence, tweaking the HAL code to try and fix it and in the end giving up and rewriting half the driver on my own anyway.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 22, 2018, 11:31:18 am
content: It's a fascinating topic, and I've been reading articles like this for 30 years since I started professional programming. None of the stuff in the article is new, and it doesn't advance any new solutions. It also doesn't have any new insight into why programming is difficult, or how it could be effectively improved.What is invariably missing from all the fine words is consideration of the commercial environment. For some organisations with a lot of resources, commercial motivation, and really smart people, they can apply advanced solutions to some specific problems, but that doesn't help all the small run of the mill places where coding takes place. They simply don't have the resources to reengineer how they write software.Progress in hardware is made because smaller features lead to faster processing, lower power, and lower cost. It's a positive feedback with win,win,win outcome. No one has found any equivalent procedure for software - my conjecture is that none exists. Writing bug free software is possible but it takes more time and money - a negative feedback that is resisted by realities of cost/benefit equation.QuoteOf course. But most people are stupid, and software only has to be slightly less stupid than people to be useful. ("You don't need to outrun the tiger, only the guy next to you")It's likely that "self-driving" cars will kill people, but overall that will be safer than letting humans drive.

author: tszaboo
author_rank: Super Contributor
timestamp: January 22, 2018, 12:48:06 pm
content: Software is made overly complex over the years, and this is done because features. Features, that are not necessary, which are the bane of reliability. Do you really need to be able to do all those things in software? Do you really need all the APIs the wrappers for the API, the abstraction layer for the wrapper? No. But someone asked for a feature, and it "needs to be done". Do you need to be able to start yourFiatJeep from your iPhone? No. But they did it anyway, and they did it badly. Are you suprised? It was probably built by a team of 50 engineers, all of them focusing on a small task, connecting the CAN line of the device to the ECU, connecting the ECU to the bluetooth module, running some legacy code written by interns.I have an error, which would require me to make changes in the linux kernel. I'm not even kidding. There is an I2C device, that I'm using, it has a software reset function, that I need to use for normal operation. When the software reset happens, it doesnt send an acknowledgement to the host, it resets, not finishing the I2C transaction normally. The hosts generates an error message.You know, what the device is? An LED driver.So because some weird bullshit requirement to be able to blink LEDs, I would need to change stuff in the linux kernel to be able to suppress error messages. Instead of fixing the code (and probably breaking someone else's code) how about getting sane requirements?There is a system with 4 requirements. Like this button does this, that button does that, this switch is for safety, it stops movement. Each function has a piece of code, which is simple and works fine. The 4 piece of code has 6 ways of effecting each other. Just draw a graph for it. When you add a 5th option, the number of these connections grows to 10. Something which we take granted, like a TPC-IP stack has billions of these connections, possibilities, that one part of the code messing up another part. Programmers can't keep track of it? I'm not surprised.

author: IanMacdonald
author_rank: Frequent Contributor
timestamp: January 22, 2018, 04:14:42 pm
content: Part of the problem is software writers insisting on continuing to use programming languages which went past their sell-by date even before Windows XP was thought of. Yet, at the same time they berate us for using 'old and insecure' software! The hypocrisy of this beggars belief.http://iwrconsultancy.co.uk/blog/badlanguage

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 22, 2018, 04:17:22 pm
content: Quote from: NANDBlog on January 22, 2018, 12:48:06 pmThe interesting thing is that ICs are far more complex than they used to be, e.g. the first pong game was a bunch of TTL logic gates. Now I can do all of that plus a lot more with a single IC, AND have hundreds of logic cells left over. The modern IC is cheaper, faster and smaller than the old TTL. (No run time software involved).So the key question is, why is increased complexity OK for hardware, but not software?

author: paulca
author_rank: Super Contributor
timestamp: January 22, 2018, 04:24:15 pm
content: The original articles focuses a little too much on non-programmers and non-business analysts cherry picking examples such as WYSIWYG and Photoshop. Woo hoo, pretty pictures, now I can visualize my code, I'm great.Maybe they should go and program in MIT Scratch and feel all warm and fluffy.You try created a billing system for an energy retailer. You receive requirements through about 3 different channels to about 3 different people in your team. The customer doesn't even understand their current business processes nor what they want their new ones to be. You fight valiantly trying to get to the details out of them, trying desperately to explain when requirements actually conflict, but they run around you and the code gets done by a junior engineer anyway.6 months later they are complaining the system is unstable.Of course it fucking is!

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 22, 2018, 04:33:38 pm
content: Quote from: IanMacdonald on January 22, 2018, 04:14:42 pmI think that is over played, I have seen buffer overrun errors in Pascal code. It would help if languages were technically better, but languages and programming techniques haven't really improved over 30 years. The biggest change in software is we have much faster hardware, compiling and debugging is orders of magnitude faster.However, it still misses the point. Programming is done in a commercial environment, not an academic one. Features and price sell products, reliability doesn't.If increased software reliability coincided with lower cost and faster development, companies would be on it like a shot. But all known techniques to improve software reliability require more skilled engineers, longer project times, higher product cost. Companies will happily ditch all that for cheap and quick, unless the customer can be charged a lot more, e.g. defense, aviation. For consumer products low cost is mandatory.In terms of market demands, automotive sits between consumer and safety critical, so it will be interesting to see how it plays out. Clearly in the Toyota case they didn't pay enough attention to safety, but many other manufacturers are treading the same line between safety, low cost and inflexible development timescales.

author: paulca
author_rank: Super Contributor
timestamp: January 22, 2018, 04:37:51 pm
content: TLA+... from the article. Lets look at one line of it.Code:Spec == Init /\ []_<<clock>> /\ WF_<<clock>>(Tick)

author: MattSR
author_rank: Regular Contributor
timestamp: January 22, 2018, 04:41:09 pm
content: I couldn’t agree more on this point. These types of programmers have no concept whatsoever of the hardware they are coding for.Quote from: dmills on January 21, 2018, 09:31:14 am

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 22, 2018, 04:46:36 pm
content: Quote from: paulca on January 22, 2018, 04:24:15 pm^^ This! It's the same nearly everywhere I have worked.Even if I could write a formal spec for the design, different product managers submit conflicting requirements. None of them would understand the spec. Even if the spec is written in plain english, getting them to read, understand and sign off is hard work. Regardless of what is agree, the requirements will change multiple time through development.I then find the engineers designated TBA1 and TBA2 are never employed, so the dev team has to develop the product with less members than planned, who also spend half the time supporting the previous project that over ran. If we refused to engage the project, it would be simply passed to another department who hires a bunch of cheap coders fresh from college, or more likely outsource to someone who does the same, except charges 5 times as much for a worse result.Saying that "if only programmers used a better programming language, products would be so much better" is kinda like saying "if only all countries used the same currency, then no one would be poor and go hungry".

author: paulca
author_rank: Super Contributor
timestamp: January 22, 2018, 04:46:51 pm
content: Quote from: IanMacdonald on January 22, 2018, 04:14:42 pmNo matter what language you use, memory is memory, pointers are pointers, offsets and vectors are offsets and vectors. All different languages do is provide a different abstraction of them. All languages are code themselves. All code has bugs.If you try and put an elephant into a cat box it will overflow. It doesn't matter if the elephant speaks English or Pascal.Enforced boundary checks? Great, so your software crashes with a boundary check message instead of overrunning the buffer. An improvement, but still ... your program crashed.Buffer overrun issues at 99% laziness or sloppiness.As someone above mentioned, software is written in a commercial environment. Often "the business" puts pressure on the software teams to get MORE functionality. The software team screams of technical debt, such as "Checking the junior engineer's buffer boundary checks" and "Code reviews", updating unit tests, bolstering the integration tests. The business hears, "We want to burn more time, spend more money and not make anything we can sell".If customers spoke code and could provide their requirements specified as critically black and white and the business / account / project managers were the programmers things would happen differently.Today the idea is to accept all these failings and to develop in fast iterative cycles. Listen to the customer, try your best to produce something that matches it in 2 weeks, show it to the customer. Take away the feedback, improve or rewrite the software, repeat.The trouble is the business / money managers again get involved and don't seem to understand the "iterative" bit. we are back to the standard.... "If you show a business manager a PoC they tick the DONE box and ask you to move on."

author: IanMacdonald
author_rank: Frequent Contributor
timestamp: January 22, 2018, 04:48:21 pm
content: "I think that is over played, I have seen buffer overrun errors in Pascal code. It would help if languages were technically better, but languages and programming techniques haven't really improved over 30 years. The biggest change in software is we have much faster hardware, compiling and debugging is orders of magnitude faster."I was referring more to security issues, but yes, any code can contain bugs. It's just that the security flaws have more serious consequences then the odd bluescreen or two.You could create a buffer overflow in a DLL call from Pascal, in fact you can do that in any language because the problem there is that the system DLL call mechanism itself is vulnerable. However, you cannot create a buffer overflow vuln in native Pascal code without doing really silly things. It is also possible to create a buffer overflow in Fortran, but again, only by doing daft things. In C, it's a question of a moment's carelessness.

author: paulca
author_rank: Super Contributor
timestamp: January 22, 2018, 04:57:38 pm
content: Quote from: IanMacdonald on January 22, 2018, 04:48:21 pmHowever, as complex as things are, what do you think the chances of boundary check enforcement being exploited?

author: filssavi
author_rank: Frequent Contributor
timestamp: January 22, 2018, 05:16:59 pm
content: Quote from: donotdespisethesnake on January 22, 2018, 04:46:36 pmThis has absolutely nothing to do with software it is the same thing in hardware, most of the times, the client has only a vague idea of what it want, it’s your job as a engineer to translate the hand-waivy explanations in specifications that can be implemented cleanly, after all if they had the expertise to define a detailed spec they could as well implement the thing themselvesCase and point, the guy next to me is working with a worldwide famous high end car maker and he is modelling components they had made to specs by a big, world famous automotive power electronics manufacturer the most time has been spent tritino to understand the specs of the object, since the carmaker (client) had absolutely no idea whatsoeverI think that the problem is entirely due to the general business model of the software companies

author: Kjelt
author_rank: Super Contributor
timestamp: January 22, 2018, 05:59:56 pm
content: With hardware the product owners and managers understand that changing it after it has been built is very expensive. They still don't get it that in the meantime it is just as costly to change software esp when it involves redesign, architecture change because suddenly some product owner woke up in the middle of the night with this great new selling feature that all customers want, one problem it was not foreseen at design time, no-one knows how long it will take to implement without a good analysis and still "stop everything" this new feature has to be made now and done in two weeks.There are new ways of working in SW country for instance we work Scaled Agile framework. We plan for 6 sprints, 12 weeks, but after 4 weeks the planning is already completely obsolete. That is how bad a SW environment can be, very dynamic.With hardware analogy it would mean someone would look at your finished hardware pcb being a DAC and tell you to change for instance the DAC because the other manufacturers part is 10% cheaper, can you finish at the end of the week? It would ruin the whole design, you have to redo many parts.

author: tggzzz
author_rank: Super Contributor
timestamp: January 22, 2018, 06:11:36 pm
content: Quote from: paulca on January 22, 2018, 04:46:51 pmIn those cases crashing isbetterthan not crashing.If you are prepared to accept incorrect results, then I can makeanyprogram significantly smaller and faster.

author: bd139
author_rank: Super Contributor
timestamp: January 22, 2018, 06:18:21 pm
content: Indeed. I tend to scatter my code liberally with assertions. Just doing a quick grep on the codebase in front of me we have 190,000 assertions. The name of the game is to not trigger any of them. If you do trigger one instead of leaving a steaming core dump it bins the thread, writes out a unique error code and logs the stack and an assertion message which is very easy to trace. Also every message has a correlation ID so we can trace the execution through all layers including storage then replay offline.Crashing is good. Design your software to survive crashes not design your software to not crash.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 22, 2018, 07:01:42 pm
content: Quote from: Kjelt on January 22, 2018, 05:59:56 pmWhen you start looking at the details of what you're actually supposed to build with the tools you have, a completely new forest little things blocks the road. We fall for this every time.

author: Marco
author_rank: Super Contributor
timestamp: January 22, 2018, 07:13:50 pm
content: Quote from: paulca on January 22, 2018, 04:46:51 pmUnless you can create better humans the use of languages which makes bugs created by lazy and sloppy humans harder to exploit would be the optimal solution in 99% of cases. If we hadn't wasted multiple decades listening to C programmers pretending that laziness and sloppiness could be overcome by just layering on more procedure.If all the effort spend on C++ would have been diverted into creating more efficient memory safe languages we'd have avoided a lot of buffer overflow exploits. Also SQL should have been designated a WMD 20 years ago.

author: vodka
author_rank: Frequent Contributor
timestamp: January 22, 2018, 07:42:54 pm
content: Quote from: filssavi on January 22, 2018, 05:16:59 pmThose problems between "The Customers" and "The Analysts" are very old. At theory, the customer have to explain the business model, as working and the fails to analyst. Now ,i think that the 90% the customers are bosses or manager who have never worked on the subordinates level,therefore the bosses don't know like work the system. Furthermore, if the analyst neither doesn't know like work customer's system and he is that says "all yes" to customer. The project will redesign 1000 times.Wherefore, the good programmers have to leave an open design for modificating the source code without have to rewrite it all.

author: MT
author_rank: Super Contributor
timestamp: January 22, 2018, 07:49:25 pm
content: Quote from: NANDBlog on January 22, 2018, 12:48:06 pmNo wonder cost of car today is 72% electronics related, according to reputable auto industry research papers.

author: janoc
author_rank: Super Contributor
timestamp: January 22, 2018, 08:02:40 pm
content: Quote from: dmills on January 21, 2018, 04:00:45 pmSince when are firewall rules responsible for ad blocking?Quote from: dmills on January 21, 2018, 04:00:45 pmSorry but you sincerely expect a lay user to be able to configure their firewall correctly so they don't get compromised by malware deployed on mass scale via web browsers??I guess you forgot the mass ransomware and virus infections - which mostly spread via drive-by downloads and exploits in browsers these days.Javascript in a browserhas no businessgenerating arbitrary network packets. If you need that, your server layer should take care of it and deliver you the result e.g. over a websocket.I am no fan of webapps or using HTML for UI (even less on embedded!) but if someone is going to do it, then please learn about the dangers first! Otherwise you (and your gadget) are risking to end up as yet another exhibit on the InternetOfShit Twitter stream.I am fed up with networked gizmos designed by people with no clue about basic information security, the main thing being that "it works" and we have shipped it, screw the end user.

author: paulca
author_rank: Super Contributor
timestamp: January 22, 2018, 08:27:30 pm
content: Quote from: janoc on January 22, 2018, 08:02:40 pmI hate Javascript with a passion. It's a rubbish language that was never intended for it's purpose, based on out of date techniques that grew warts, heads, arms and legs in all different directions and has only recently be 'tamed' in any way at all. Mostly due to VERY heavy compatibility frameworks behind things like Angular and React.It should have remained a sandboxed, interrupted automation framework for making text flash and scroll. We should have come up with something better rather than struggling on with it.I'm actually fairly angry that spectre and meltdown have javascript as a vector. That's just dumb. who let it out of the browser interrupter and why? Don't start me on the f'ing script kiddies getting on the server with Node JS either. Piss off back to playing with "Poke your boss in the eye" apps and learn a real language if you want to play with the real toys.Though I do know why unfortunately. Business and money. Why put 8 servers in your rack and generate HTML when you can put 2 servers in your rack and send JSON, let the browser do all the hard work and use clients electricity and CPU.

author: tszaboo
author_rank: Super Contributor
timestamp: January 22, 2018, 08:28:58 pm
content: Quote from: MT on January 22, 2018, 07:49:25 pmAnd that is the part, which keeps on working. At least I never hear that in the service, they need to replace the ECU and the cabling and the software after 100Km, because it wore out. It is always some mechanical fluidy plastic thingy which rotates and breaks because you dear using it.

author: Vtile
author_rank: Super Contributor
timestamp: January 22, 2018, 08:44:18 pm
content: Quote from: NANDBlog on January 22, 2018, 08:28:58 pmNah. Moisture here and there, lots offaultsfeatures inelectroniccars. Door harnesses are the worst, second to the "automatic" pressure valves in tyres.Obviously this topic should be splitted to realtime software and software. Realtime software have many times tentacles outside the CPU & memory structure in form of realworld loops backs.

author: paulca
author_rank: Super Contributor
timestamp: January 22, 2018, 08:54:52 pm
content: Quote from: vodka on January 22, 2018, 07:42:54 pmYes. This leads to the current mess we called Enterprise Java.Design by "But what if...""Design a piece of software to help someone walk.""But what if they have only 1 leg?""What if they have 3 legs?""What if someone has no legs?""Should we support cats too?""Well if we are supporting cats, why not dogs?""Gerbals?""What about wheels?"2 years later what should have been done in a week is STILL in development. The lead engineer and his favourite side kick are the only ones who understand WTF is going on in a HUGE MASSIVE death star of a frameworked application. Thousands of abstract classes, each with single implementations below interfaces.2 years later the customer says, "We have client who uses his arms to walk."BOOOOM!!!!!Now the 2 week application would take about another week to change to support 2 arms. The "Death StarTM" takes another 2 years.The people who have to support it in the wild leave the company because it's just too difficult and they can't stand working with it.It's consultancy 101 if you are developing an application for someone else that you can walk away from, being paid by the day, make it as complex as possible, throw the kitchen sink and the full family wedding gift list at it. Make sure only you and your team understand it. Charge by the day.This, currently is my nightmare and it's happening to me all over again. My solution is to follow the agile process and design underneath them, get the damn job done, evaluate and move forward while they construct their Death Star.

author: Berni
author_rank: Super Contributor
timestamp: January 23, 2018, 06:11:26 am
content: Unclear and ever changing specifications are indeed the worst in programming.You can try to make the code simple and to the point but then when they ask for a new killer feature means that a great deal of code has to be rewritten to support it. If you make the code broad and universal to cover lots and lots of "what if" scenarios then the code becomes a huge tangled mess where everything in some convoluted way depends on everything else. Now you are digging trough all that crap to find that magical function that can do the feature, only to find that that function is sort of half broken and you need to waste even more time trying to debug why it doesn't work.

author: Kjelt
author_rank: Super Contributor
timestamp: January 23, 2018, 08:40:46 am
content: Todays Dilbert is ontopichttp://www.dilbert.com/strip/2018-01-23

author: tggzzz
author_rank: Super Contributor
timestamp: January 23, 2018, 09:08:01 am
content: Quote from: Berni on January 23, 2018, 06:11:26 amToo limited: change "programming" to just about anything you like. Examples: hardware, lawmaking, renovating kitchens, etc etc etc

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 23, 2018, 09:40:28 am
content: Quote from: paulca on January 22, 2018, 08:27:30 pmYou're talking complete bollocks. And again, Javascript != DOM.

author: paulca
author_rank: Super Contributor
timestamp: January 23, 2018, 10:12:34 am
content: Quote from: GeorgeOfTheJungle on January 23, 2018, 09:40:28 amWell thank you for that elaborated correction to my opinion. I am perfectly aware of what DOM is thank you and I'm not sure where I said Javascript == DOM.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 23, 2018, 12:47:30 pm
content: Quote from: paulca on January 23, 2018, 10:12:34 amOk, sorry, if that was rude I apologize. There are despicable javascript fanboys and there are too, despicable javascript haters (*). Let's leave it at thatI'm not a fanboy but I've had to learn JS and write many tens of thousands of LOCs in Javascript and it's actually a pretty good language, Javascript, not the DOM (see "An Inconvenient API - The Theory of the DOM" @youtube).(*) Most of which confuse the DOM with JS, and/or can't grasp why JS is no C nor JAVA: different scoping rules, closures, prototypal inheritance, no classes, asynchronous/evented execution, etc.

author: paulca
author_rank: Super Contributor
timestamp: January 23, 2018, 01:00:02 pm
content: Quote from: GeorgeOfTheJungle on January 23, 2018, 12:47:30 pmWe can disagree on the language. I worked with developing Javascripts frontends for several years in the past and I still hate it.It's really scheme or closure with scheme/closure crossed out and Java written in as a marketing ploy. Until the ECMA standards came in it wasn't really a language at all, it was a collection of hacks each one different in each browser. In part it STILL is. It's just that we have frameworks today that hide this and work around the browser implementation oddities.It's dynamic typing is fairly retarded and sometimes extremely irritating. The scope is bonkers. Everything seems to be a function that takes a function as an argument and returns a function that takes a function as an argument. Recursion and callback-tastic. It's object orientation is just broken.The only good thing that came out of Javascript was JSON, which thankfully shut the XML fan boys up enough that we managed to get away from slow, verbose, cumbersome DOM structures and immensely inefficient parsing.

author: bd139
author_rank: Super Contributor
timestamp: January 23, 2018, 03:30:14 pm
content: JSON is shit. Bad numeric types, no reliable schema implementation, terrible Unicode problems. Nothing to like. It’s 2017’s CSV that fell out of the JavaScript crack pipe.BSON fixes some of that shit but just use protobufs or something instead.XML is one of those things that will outlive us all and be determined that it was a good idea after all but not until, like all human progress, many things have died first.

author: paulca
author_rank: Super Contributor
timestamp: January 23, 2018, 03:55:40 pm
content: Quote from: bd139 on January 23, 2018, 03:30:14 pmBinary. Yuk. I can see so many annoyances with that. Like having to use form-mutlipart MIME and all that good stuff over HTTP. Needing encoders, decoders and having binary blobs in your unit tests.XML is just too bloody heavy and slow or cumbersome to parse/generate.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 23, 2018, 05:20:26 pm
content: Quote from: paulca on January 23, 2018, 01:00:02 pmThere is your error, again: JS is and has always been 100% compatible among browsers, the DOM is what is not.QuoteDynamic typing is fine, automatic type conversion (casting) not so much, you've got to be careful and know what you're doing or if not avoid it altogether, which is easy to do.The scope thing is not a problem unless you tend to write too long (in LOCs) procedures (functions), which is not a good idea anyway.The everything is a function and the callback-tastic thing you mention is done exactly like that in C too when/if your program is event-driven, but, as C has no closures you've got to create tons of structures, or objects in C++, in which to save the context that you've got saved for you for free, in the closures in JS.Wrt the objects, that's what people coming from classical inheritance repeat ad nauseam, but you know what? More often than not there's no need to classify objects, nor any need to declare classes, and most of the times you don't even need your objects to inherit nothing at all. And there you go: in JS you can simply create them as you like as you need on the fly at runtime (procedurally not declaratively) without any hassles.As I said before "haters can't grasp why JS is no C nor JAVA: different scoping rules, closures, prototypal inheritance, no classes, asynchronous/evented execution, etc." and you've just now proved my point again.QuoteYep, and this is what Dave Winer (of xml fame) had to say about it: "Who did this travesty? Let's find a tree and string them up. Now.". Lol, nobody sane uses xml anymore.

author: bd139
author_rank: Super Contributor
timestamp: January 23, 2018, 05:24:31 pm
content: We still use XML. Find me a better interchange format for financial data. One that doesnt have arbitrary precision depending on which vendor’s butt you sniff, has full schema validation, signing, binary embedding that we can stream on the fly about 50 gig of it in one stream with an event driven parser...Thou who doesn’t understand XML is doomed to reinvent bits of it poorly.Dynamic languages can fucking die. We’re too dumb to even manage strict typing. Let’s make things even less correct so the monkeys can dance around the pile of shit that has been created (incidentally I’ve written hundreds of thousands of lines of python and it’s horrid).As for JavaScript, it barely works. It’s the next php.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 23, 2018, 05:32:31 pm
content: Well yes perhaps banks can't change, but paypal is 100% xml-free.

author: Marco
author_rank: Super Contributor
timestamp: January 23, 2018, 05:40:30 pm
content: Quote from: GeorgeOfTheJungle on January 23, 2018, 05:20:26 pmIf it's only easy to avoid, then with enough programmers and enough LOCs it won't always be avoided in the end. That's why large companies have been forcing statically typed variants on their programmers. Not possible is better than easy to avoid.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 23, 2018, 05:55:57 pm
content: But static typing only saves you of a very tiny % of program errors and can generate others of its own (e.g. could not load this or that DLL version), so I gladly prefer to be relieved of the slavery of having to choose and type every fucking var type beforehand for not much benefit if any. And I'm not saying it's not ok for C and systems programming, I'm just saying that for apps and the web it's not a must, it's more a needless hassle.

author: bd139
author_rank: Super Contributor
timestamp: January 23, 2018, 06:24:30 pm
content: Quote from: GeorgeOfTheJungle on January 23, 2018, 05:32:31 pmPayPal’s logic and use cases are pretty trivial in the scale of things. They just do a lot of trivial things at once.Try financial compliance or product sales. That’s a different ball game.

author: Marco
author_rank: Super Contributor
timestamp: January 23, 2018, 06:38:35 pm
content: Quote from: GeorgeOfTheJungle on January 23, 2018, 05:55:57 pmUnfortunately Javascript has migrated to server side. Dynamic typing with automatic casting is one of those features which just have an inordinately high chance of creating exploitable bugs, doesn't belong on anything internet facing which deals with sensitive data.

author: paulca
author_rank: Super Contributor
timestamp: January 23, 2018, 06:44:28 pm
content: Try stock exchanges order entry or market data. Most systems will have raised a dozen orders before your Sax parser has parsed the first message. FIX or binary variants.XML is great for B2B communications when neither end could previously agree on a standard format let alone properly publish what they format actually is. Now everyone has an XML Schema for their messaging and if you don't like it pass it through XLST and make it what you want. But... it's incredibly expensive. On the wire XML is usually 60-80% meta data.It's all tools for the job. You don't put an buck converter into a 12V circuit to run a 3.3V MCU that pulls 20mA. Yet some people hate linear LDO regs and vice versa.If you want to grep a log file and produce a summary or extract a one flow from 100 concurrent ones, you don't write a C program to do it. You would use perl or python.The more tools you have in the box the better, as long as you know when and where to use them. If I need to do something dynamic in a browser I will use JS, but I won't like it. I still wish there were better alternatives.And... as to JS <> DOM. Can you explain to me what exactly you can do with JS in a browser that doesn't involve the DOM? It's a bit daft saying that JS is fully 100% compatible across all browsers, it's the browsers that have different DOM and Window and API implementations etc. etc. Without those things JS is pointless and mute.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 23, 2018, 07:11:01 pm
content: Quote from: Marco on January 23, 2018, 06:38:35 pmNice try, sounds good, seems plausible! But no. And again, Paypal... for example (and a zillion other online businesses).https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 23, 2018, 07:17:25 pm
content: Quote from: paulca on January 23, 2018, 06:44:28 pmThat one is easy: without the DOM (*) JS can do nothing.(*) this is from the ecma specification. JS (the language) provides no means for I/O, look:"OverviewThis section contains a non-normative overview of the ECMAScript language.ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment. ECMAScript as defined here is not intended to be computationally self-sufficient; indeed, there are no provisions in this specification for input of external data or output of computed results. Instead, it is expected that the computational environment of an ECMAScript program will provide not only the objects and other facilities described in this specification but also certain environment-specific host objects, whose description and behaviour are beyond the scope of this specification except to indicate that they may provide certain properties that can be accessed and certain functions that can be called from an ECMAScript program."JS on the server side (node.js) has no DOM, but provides other objects to do I/O (that are not part of JS "the language").

author: dryjoints
author_rank: Regular Contributor
timestamp: January 23, 2018, 07:33:10 pm
content: WhathaveI triggered...

author: tggzzz
author_rank: Super Contributor
timestamp: January 23, 2018, 07:50:20 pm
content: Quote from: GeorgeOfTheJungle on January 23, 2018, 05:55:57 pmStatic typing is very useful. Nothing, including static typing, is a complete panacea.Thus spake someone that hasn't had to contend with "doesNotUnderstand" messages (or more recent variants of the same concept!) appearing at runtime - rarely and unpredictably. Doubly so when part of the code that might be the cause was written by somebody else in a different company that no longer exists.Thus spake someone that, when trying to use such code libraries, hasn't cottoned on to the wonders ofaccuratecntl-space completion.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 23, 2018, 08:18:16 pm
content: Ohh yes, the wonders of auto-completion: when in doubt hit ctrl-space.

author: bd139
author_rank: Super Contributor
timestamp: January 23, 2018, 08:38:36 pm
content: Followed by Visual Studio has stopped responding.

author: tggzzz
author_rank: Super Contributor
timestamp: January 23, 2018, 09:44:42 pm
content: Quote from: GeorgeOfTheJungle on January 23, 2018, 08:18:16 pmMore than just "when in doubt" - also very good for "I can't be bothered to type all that" methods of reducing risk of RSI!I've never understood why people rail against Java for too much typing, since that is very significantly reduced by cntl-space. My best guess is that they have come from a C/C++ background where autocompletion can never be as good.

author: bd139
author_rank: Super Contributor
timestamp: January 23, 2018, 10:59:12 pm
content: Indeed. Cut and paste and Ctrl+tab your way to a finished product.Java is really just glue for all the nice canned libraries out there that do all the hard stuff. When knocking anything Java out I have to write very little code. I mean hardly anything. Data import, meh import smooks and cut and paste for 20 minutes and you've got CSVs, XML being streamed into hibernate ...

author: tggzzz
author_rank: Super Contributor
timestamp: January 24, 2018, 12:29:47 am
content: Quote from: bd139 on January 23, 2018, 10:59:12 pmI've never been able to cut-and-paste my code!But the not having to write much Java code is significant. When I started using it (in 1996/7 when it had only just been released) I was pleasantly surprised at how easily I could obtain interesting relevant special purpose high-quality libraries in a way that had C++ had failed to do in a decade. And all the libraries played nicely with each other, cf C/C++.A very pleasant vindication of my belief that Java was worth learning - in a way that Delphi/C++/C# weren't.

author: Marco
author_rank: Super Contributor
timestamp: January 24, 2018, 01:24:25 am
content: Quote from: GeorgeOfTheJungle on January 23, 2018, 07:11:01 pmWhat about PayPal? They use Java server side.Meanwhile Facebook, Microsoft and Google all have their own version of typed Javascript (with a few more out there).

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 24, 2018, 02:26:43 am
content: Quote from: paulca on January 23, 2018, 06:44:28 pmActually, there do exist micropower buck converters for where even that tiny amount of power matters.https://www.maximintegrated.com/en/products/power/switching-regulators/MAX17530.html

author: rhb
author_rank: Super Contributor
timestamp: January 24, 2018, 03:28:16 am
content: Come the revolution we kill the programmers first. The lawyers can wait.Seriously, having spent a lot of time fixing a few million lines of other people's code, I have little more than contempt for most programmers' work product. I wrote a couple of 15,000 line libraries that had NO bugs found in almost 20 years of use. Can it be done? Yes. Is it easy? No. You actually have to care about what you do. And write meticulous test cases.My most outrageous experience was a conversation with the support guy for a piece of software my employer paid $80,000 a year in support costs. I had gotten involved when it would not work on multiple systems. After several days of BS, the guy said, "If you find a fix, please send it to me so I can give it to the other customers." They had to peel me off the ceiling with a putty knife.I've got 80 feet of computer books to go with my attitude. And, yes, I've read them, except for things like the X11 and Motif manuals which are just for reference.

author: Red Squirrel
author_rank: Super Contributor
timestamp: January 24, 2018, 04:45:20 am
content: The big issue is when there is no failover plan or redundancy. In this case, something as simple as tracking number of calls should NOT actually affect the possibility of those calls going through. Zero reason for that. It should raise an alarm that the service that tracks it is not working but the calls should still go through.Software/technology should enhance things but those very things should still be designed in a way that they can work without those enhancements, if they are life critical.I've worked IT in a hospital and it's scary how many critical things rely on some crappy piece of software running on an old Dell Optiplex GX1xxx era PC sitting inside the ceiling or behind a desk somewhere that nobody really knows about - not even IT.I work in telecom now, and it's incredible how redundant and robust stuff is designed - especially the older stuff like DMS switches.

author: tggzzz
author_rank: Super Contributor
timestamp: January 24, 2018, 08:11:49 am
content: Quote from: rhb on January 24, 2018, 03:28:16 amI think you mis-spelled "... for punishment".

author: tggzzz
author_rank: Super Contributor
timestamp: January 24, 2018, 08:14:22 am
content: Quote from: Red Squirrel on January 24, 2018, 04:45:20 amYes indeed. Until you see how various systems are patched together.The top-level deployment level diagrams for telcos resemble cold spaghetti. There are even companies that make software whose sole purpose is to connect two different systems together.

author: nfmax
author_rank: Super Contributor
timestamp: January 24, 2018, 09:50:04 am
content: Quote from: bd139 on January 23, 2018, 10:59:12 pmI like to make an analogy with those fancy 'Corian' or whatever kitchen worktops - mostly made up of ground-up hard stuff like quartz or granite, bound together and made shiny by the smallest possible quantity of plastic resin. The hard stuff is like the libraries, the soft resin is the code you have to write make it all stick together and look shiny.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 24, 2018, 10:23:13 am
content: Quote from: Marco on January 24, 2018, 01:24:25 amhttps://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/QuoteTypescript and etc. are good for (ex-java) programmers that can't live without ctrl-spacebut in the end it still compiles to javascript:https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js

author: paulca
author_rank: Super Contributor
timestamp: January 24, 2018, 10:51:52 am
content: One of the main problems in the industry is lack of talent.I don't mean that sarcastically either. Literally lack of talent. In the UK schools, primary and high school have completely trashed the reputation of "IT" as a career by reducing it down to "ICT Skills" which is then implemented by teaching kids how to use Microsoft Office. 99% of kid immediately go "Sod that I'm not doing a career in IT! No way!"After 20 or so years of this the number of IT graduates coming out of universities has diminished while the demand for software continues to increase. The net result is that companies I have worked for now recruit via transfer courses to take people with any degree (or no degree at all), put them through a 6-12 week "Academy" and plonk them into a programming or analyst career.Worse is that the senior engineers are very often not given enough time or resources to continue their training.So dodgy, miss guided, naive code becomes the norm and people like myself simply don't have the time to review, rewrite and education to correct it.If you want an idea of how bad it gets just look at the code that floats are EE forums. (Hell I'm guilty of it, the difference is understand my code is "PoC" at best). A lot of people believe the sketch they download from AdaFruit forums and works constitutes completed code. In that context we need to do our due duty and remind people that that level of coding is the equivalent of a breadboard project. The real project will expand a lot once proper error handling, refactoring for test-ability etc. etc. id conducted. In a similar way to how an electronics project expands as it moves from a breadboard hacked test to a product.

author: tggzzz
author_rank: Super Contributor
timestamp: January 24, 2018, 11:15:04 am
content: Quote from: paulca on January 24, 2018, 10:51:52 amYou've missed one otherveryimportant factor. Recruitment agents and HR-droidsactivelyregard people over 35 as PSBD (past sell by date).

author: Kjelt
author_rank: Super Contributor
timestamp: January 24, 2018, 12:21:10 pm
content: And still it is more complex since even good experienced programmers have their own WOW , their own coding styles and guidelines which are not always (pun intended) compatible.Very simple example:Some SW engineers write defensive code, in the function they start verifying the input parameters for validity and even output parameters like pointers to buffers.Other SW engineers or a "guru" like uncle Bob say don't do this, it makes the function unreadable hard to understand and messes up lean clean coding. Their point is that the test framework should prevent that these functions are called with incorrect parameters.So who is right? I think both or none it depends on the company. In my company we have seperated the task of writing the testframework from implementing the code, you bet that in this case where there is no hard binding in time between the testframework and the implementation uncle Bobs WOW might fail miserably. That is why uncle Bob says that the SW engineer should first write the testframework himself, when finished start coding. That sounds expensive, the SW engineer should write at least double the code and probably in embedded cases in two different languages.Only a simple example and in practice there are tens of this sort dilemmas that easily could ruin your product.

author: @rt
author_rank: Super Contributor
timestamp: January 24, 2018, 12:58:45 pm
content: The programmers would know best what their software can and cannot do, but probably like being paid.I think just about every new technology is rushed in too fast.Spaghetti thing makers are a prime example.It will be another ten years before I'd even look at a spaghetti thing maker.

author: tggzzz
author_rank: Super Contributor
timestamp: January 24, 2018, 02:01:36 pm
content: Quote from: @rt on January 24, 2018, 12:58:45 pmThe analogy between software tools and kitchen tools isn't a bad analogy. Good questions:can I do new thing Y with new tool X?can I do new thing Y with the tools I currently have?if not, what else could I use to do new thing Y?does new tool X interwork with my existing experience and tools, or am I having to start from scratch?is there a sustainable ecosystem around new tool X?what happens when tool X's manufacturer stops?Most new tools X fail at least one of those tests.Most new kitchen implements also fail the "does it take longer to clean it than the time saved using it?" test.

author: Kjelt
author_rank: Super Contributor
timestamp: January 24, 2018, 02:07:00 pm
content: QuoteThat reminds meHaving a seperate research department that creates prototypes, mostly PhD's and academic persons that are excellent in creativity and making fast working prototypes and that is what they are paid for.Then the managers see the prototype demonstration andthinkthat it is ready for production, it works so the rest is just a month work or something like that.Yeah right these great minds are good in building something fast which has its value and grant them that, but they have zero knowledge of writing good software that is production ready.If you are lucky the software handles all sunny day scenarios but that is it. It works for a couple of hours than has to be reset and if you look at the software you practically have to start from scratch. Algorythms are usually ok'ish but the architecture, lack of design (patterns) and spaghetti code where exceptions are unhandled is disastrous.Try to explain management that the demo they saw is a rust bucket with a thin golden layer on top which works for a day at most , and to be able to put it in production the whole chassis has to redesigned.

author: Marco
author_rank: Super Contributor
timestamp: January 24, 2018, 02:10:04 pm
content: Quote from: GeorgeOfTheJungle on January 24, 2018, 10:23:13 amThat predates the widespread adoption of typed Javascript, more importantly though they seem to havemoved back.

author: bd139
author_rank: Super Contributor
timestamp: January 24, 2018, 02:28:59 pm
content: Can I stretch the kitchen analogy further because I think it's a really good one. This turn out a bit longer than expected but this is the shit that goes around in my head all day while facepalming at failing and miserably shit software teams:I am quite adept with a single Santoku knife I paid a £20 for, to the point I can usually cook ANY meal with just that, a table fork and a couple of pans or trays efficiently, reliably and quickly. I've had it for 20 years. Unfortunately, sometimes the wife comes along with the garlic crusher, the mixer, the strange peeling devices, the odd shaped single use tins, every frying pan, dispensers etc. She does this because she saw someone on television doing it and felt that's how she should be doing it. She was inspired to try these new ways of doing things to solve the same problems she had before. There is no rational reason that the solution is any better. The result, as tggzzz so elegantly put it, is nothing but more washing up.A big problem with technical leads is their almost religious following of ideologies which are promoted by the tech equivalents of Nigella Lawson and Jamie Oliver etc. The promoters of these ideologies have unstoppable momentum via conferences etc which result in the ideologies being adopted without rational analysis. When you go to these conferences, they are full of people looking for an ideology as well. This bolsters the new way of thinking even further. The next thing your tech leaders do is come back as freshly converted Jehovas Witnesses or something even worse like DDD or devops proponents.Then this leads to the question of discipline. How do you get 50 people to conform to a certain ideology that they really don't actually give a fuck about? Well it turns out that someone has this wonderful tool which makes it all good. So they buy 50 fucking garlic crushers and make them crush garlic all day. Then you find that the things get jammed up with shit, so you have to hire someone to unclog the crushers. This poor team of uncloggers feels unfulfilled and starts to bail out. Management are annoyed that their entire delivery cycle is being ruined so start putting some pressure on the technical leads. Then someone else comes along with another ideology which conveniently solves this problem. This ideology is getting the end users to unclog their own garlic crushers. Now the fresh uncloggers don't have time to do this because they're already expected to be churning out crushed garlic pretty quickly because of the management pressure and now they have to learn how to unclog the crushers. At the end of the day, velocity and quality decline, no one gives a fuck and everyone leaves to work for a company that has apathetic management who don't want you to crush garlic all day and never go to conferences, because that would actually create them more work.And that's how you fuck up a software company.Don't buy into an ideology, stay away from complex tools, keep it simple, be lazy, use decisive small tools.Personally my favourite stack is: centos, vim, valgrind, gdb, make, svn and bugger all else.

author: MT
author_rank: Super Contributor
timestamp: January 24, 2018, 02:31:53 pm
content: Quote from: NANDBlog on January 22, 2018, 08:28:58 pmNope, just gently moist or flood a car (Texas/Flordia/Djungle/damp costal regions) and you get a car that's going to show all kinds if electrical problems including complete rewiring and ECU replacement. My current car have shownway more electrical failures then mechanical and the mechanical i can fix my self.Mind you the trend of autonomus cars i recall was not initiated by auto industry rather from the IT EE folks , theylike Philips deliberately creates a imaginary problem that needs a imaginary fix (personal kitchen 19.99usd baking machine). What do bakers think about Philips?When software are able to fix outback road driving (Siberia etc) then just inner city then we can talk about global automatically driving, if its even desirably.

author: @rt
author_rank: Super Contributor
timestamp: January 24, 2018, 02:43:17 pm
content: I needed a washer once, to insulate a standoff in the middle of the washer, from the conductor on the outside of the washer.It was to be clear acrylic with a silicon layer each side of the washer, and I offered to pay a tidy sum for something so simple.The first try was a fellow proud of his spaghetti creation. It was laughable, but wouldn’t do any damage to try it.

author: IanMacdonald
author_rank: Frequent Contributor
timestamp: January 24, 2018, 02:48:21 pm
content: Just met a case of this. Set up a high value banking transaction which involved entering a 20-digit number and other details with great care. Was then told I had to wait for a mobile phone message for two-factor auuthentication. Only, this is a new feature and they haven't told users to give them a mobile number yet.So, went to the personal details page and tried to enter a number. Was told that the number could not be accepted because the existing number was {blank}. Well, yes of course it is because..This is a typical syndrome with programmers. They simply have no real world commonsense. They can write 20,000 lines of utter gibberish, but can't think through even a simple real-world action. If they had to tie their own shoelaces they'd do so first and then try to put the shoes on.Another big problem with software these days, especially browser software, if there's any problem at all,PHUT!and everything you've entered is gone. In the old days they used to remind us to back up regularly. Now, the systems provide no way of backing up so as soon as there's a glitch you lose the data.

author: bd139
author_rank: Super Contributor
timestamp: January 24, 2018, 02:50:32 pm
content: Capital One did that recently. They introduced 2FA and fucked it right up.

author: tggzzz
author_rank: Super Contributor
timestamp: January 24, 2018, 02:50:48 pm
content: Quote from: Kjelt on January 24, 2018, 02:07:00 pmWhen Java Swing GUI programs were a hot thing, there was a very useful "skin" that could be used in such circumstances: "napkin skin".Its purpose was tolooklike something scrawled on the back of a napkin, so that itsignalled"prototype". All the GUI widgets worked as you would expect, but the background was crumpled paper and the text was handwriting.

author: tggzzz
author_rank: Super Contributor
timestamp: January 24, 2018, 02:51:58 pm
content: Quote from: IanMacdonald on January 24, 2018, 02:48:21 pm"FSMs? What are they? Oh yes, I seem to remember something about them being used in compilers."

author: bd139
author_rank: Super Contributor
timestamp: January 24, 2018, 03:03:56 pm
content: That's even pushing it a bit. Most people glaze over if you mention any algorithms. They are the same numpties who think LINQ is the best thing ever, then it hits production and they didn't realise that it's just a fancy iterator implementation and doesn't scale as well as it did when they tried it on 6 objects in test.Also I added a simple hand coded state machine for parsing some streaming data once and was asked to remove it because no one understood it. I was told to replace it with a big regular expression. Which would be fine but the fucking thing was not a regular language...Aaagghghghgh thank fuck I work in an office graced with more than one copy of the dragon book now.

author: paulca
author_rank: Super Contributor
timestamp: January 24, 2018, 03:45:16 pm
content: Quote from: IanMacdonald on January 24, 2018, 02:48:21 pmIan I think part of your perception is that you believe it's one programmer or one team. It's most likely a dozen different teams in a handful of different countries.Team one has been told to enforce 2 factor authentication in the REST teir.Team two has been told to implement the web UI components for it.Another team has implemented the SMS gateway.Another team has done the data access layer.Another team has done the database changes and stored procedures.Another team manages the interconnect messaging bus.Another team has been told to make phone numbers mandatory on another part of the UIYet another team has tested part of it.Yet another team has tested another part of it.Finally another team did pen testing and vun testing and proposed changes back to all of the teams above.Management and business didn't factor in the time to fix these security concerns and rushed them through, probably asking people to work until 11pm for a week!All of them are working with partially complete requirements and test plans written by partially incompetent BAs. The Project managers and scrum masters who job it is to make sure changes synchronize across all the teams for a release are probably barely sentient.So most likely the programmers all did what they were informed they were supposed to and only had a limited view of one or more parts of the overall solution. I can guarantee you that 90% of them never, ever looked at the public version of the website.Someone somewhere dropped a ball, probably in final UAT testing. Or maybe it was a deployment issue.With my lead developer hat on, I would guess what has happened is that the requirement for the two factor stated:WHEN customer.PhoneNumber is NOT NULL or ""But previously they had used the value {blank} in place of NOT NULL or "" for a version back in the past.Nobody remembered this across all the teams and nobody tested it and ... BANG.

author: dryjoints
author_rank: Regular Contributor
timestamp: January 24, 2018, 03:46:56 pm
content: Software:> Nothing set in stone (except stupidity, perhaps).> What works one week, will have been "upgraded" or "deprecated" the next, breaking your machine.> You cannot SEE what is broken, or smell that it's broken, or feel it getting hot.> You spend your entire working life staring at a screen or ten.> There is NOTHING physical to present with pride to show a family member or colleague; software is - at best - abstract, meaningless gibberish to the average mortal.Hardware:> Subject to the unchanging laws of physics, constants that are rock solid and can be measured, logged and relied upon ALWAYS.> You can see what's broken through symptoms, dry joints, burnt out components etc.> You can grab your latest creation, take it home and show it off to your family; "I just made this!" beaming with delight.

author: paulca
author_rank: Super Contributor
timestamp: January 24, 2018, 04:09:09 pm
content: Quote from: dryjoints on January 24, 2018, 03:46:56 pmUntil in the middle of the night it develops a fault induced by a mistake in a datasheet you trusted and sets fire to your dog, burning the rest of the house down and killing your parents... and your dog. You spend the next 10 years learning to program software from prison while serving a scentence for involuntary man slaughter

author: tggzzz
author_rank: Super Contributor
timestamp: January 24, 2018, 04:18:37 pm
content: Quote from: bd139 on January 24, 2018, 03:03:56 pmAt university I decided I would never (1) have anything to do with compilers, and (2) ditto databases.I manged (1), and my involvement with (2) was to throw the damn thing out and replace it with a replicated distributed in-memory key-value store.Muchmore efficient

author: bd139
author_rank: Super Contributor
timestamp: January 24, 2018, 04:26:02 pm
content: Quote from: tggzzz on January 24, 2018, 04:18:37 pmMusic to my ears. We use Riak for a lot of stuff which fits that criteria. Actually we ripped off a lot of our architecture from the NHS's spine2 projectLevering the organisation off relational databases is hard though so there's a ton of SQL Server instances still left.Only problem is Basho has gone down the shitter so we're going to have to hire a couple of good Erlang guys in to look after it. They're still cheaper TCO than one SQL server instance on the scale we need.

author: tggzzz
author_rank: Super Contributor
timestamp: January 24, 2018, 04:27:50 pm
content: Quote from: dryjoints on January 24, 2018, 03:46:56 pmOK, what's the erof your FR4 PCB? I take it you haven't designed+implemented any modern logic circuits or microwave filters etc.Or, for that matter, what's the speed of light?QuoteSometimes, as with my latest toy (a Tek 485), the only symptom is "the PSU is clicking on/off". I hope it ends up being merely aninvisiblyshort circuit tant cap, or aninvisiblyhigh ESR cap.QuoteTrue.

author: paulca
author_rank: Super Contributor
timestamp: January 24, 2018, 04:32:15 pm
content: Quote from: dryjoints on January 24, 2018, 03:46:56 pmSoftware:> You can upload it to the internet, announce it on a mailing list and the whole world can see it and you become a household name and a millionaire in a week.Linus TorvaldsMark ZuckerbergBill gateset. al.

author: bd139
author_rank: Super Contributor
timestamp: January 24, 2018, 04:42:15 pm
content: Sometimes goes a bit wrong though:https://en.wikipedia.org/wiki/TempleOS

author: Vtile
author_rank: Super Contributor
timestamp: January 24, 2018, 05:19:36 pm
content: Quote from: bd139 on January 24, 2018, 04:42:15 pmAt least teh programming language which were used to create the TempleOS is spot on as HolyC. The holy language of the ceremonial programming tasks, the almighty software geekery.

author: dryjoints
author_rank: Regular Contributor
timestamp: January 24, 2018, 05:50:09 pm
content: Consumer software appears to work like this (Android, Windows, I'm looking at YOU):• "Look at this puny truck we have, we can only carry 1 ton of sand on this; we need a bigger truck"(Buys bigger 'truck' [CPU, RAM etc])• "Look at this GIGANTIC new truck! I'm so glad we bought this, it's rated at 10 tons... but I'm sure we can squeeze 15 out of it, and if we switch to a cheaper fuel grade we can get more out of our purchase."So, you have the latest hardware, it's not fast enough to keep up with your bloated mess of an OS that's about to ship, so you develop faster hardware instead of optimising your shiny new blob of tangled binary spaghetti, rinse and repeat, and it had the convenience of driving totally unnecessary hardware sales.Schmucks.

author: Zero999
author_rank: Super Contributor
timestamp: January 24, 2018, 06:30:54 pm
content: Quote from: dryjoints on January 24, 2018, 05:50:09 pmThat no longer seems to be the case for desktop PCs. I'm sitting here, quite happily using a 12 year old PC, with a modern OS. The only upgrades were the RAM (1GB to 3GB) and a solid state hard drive. Now, go back to 2006 and see if you could use a 1994 era PC: even with the RAM and hard drive upgraded, it still wouldn't run a modern OS and browser, without falling over.

author: John Coloccia
author_rank: Super Contributor
timestamp: January 28, 2018, 03:31:47 pm
content: Quote from: bd139 on January 23, 2018, 03:30:14 pmSort of have to agree with this. I don't have anything in particular against JSON/BSON. I think it is a nice, lightweight pattern that works well for basic configuration and data exchange. If I needed something like that, I'd have no problem using JSON, especially if my environment supported it directly.That said, I think XML is what you use when you need more sophisticated structures and/or you're not sure what you'll need in the future. I think they peacefully coexist with each other. In fact, I'll say that a very powerful idea is to use JSON for things JSON is good at, and reference/embed those things in the overall XML file that describes the rest of the system/data. I've read where people claim this is an awful idea for various philosophical/ideological reasons. I'm not much of a philosopher, and I don't have any ego wrapped up in these various technologies, so I try not to pay too much attention to all the blather and just let the project dictate the design, even if that means breaking a bunch of silly rules.Unfortunately, I still have customers that want to use their own made up file formats. They're usually simple enough that it's not worth fighting it, and you just build a simple parser to do it. It's not a big deal, but it's just not efficient or wise to make up your own config file format these days. There are so many options, why not just pick something like JSON or XML and be done with it?

author: paulca
author_rank: Super Contributor
timestamp: January 28, 2018, 07:56:03 pm
content: You don't see ICs sending XML or JSON over SPI.If the knowns are known, binary wins on the software side, impossible without a bitwise header for all client languages needed. If the knowns are unknown then a flexible format like JSON if typing is not a problem or it's 99% strings, especially for display. XML is for when the format has to be flexible and precise/prescriptive.Don't build the Forth Bridge to cross every puddle.

author: bd139
author_rank: Super Contributor
timestamp: January 28, 2018, 08:56:06 pm
content: Just a point; XML is misunderstood here still. Don’t assume it’s just the markup. It’s a vast and powerful tool. The semantic structure actually lives on its own. For example if you have an XSD, you can compile it to any transport or parser implementation. It doesn’t have to target or validate markup. It can even generate code.We wrote a compiler which compiles entire XSD specified documents into compressed serialised binary event driven parsers which sit at either end of a network channel.Where people think of markup, we’re farting around a few tens of bytes of data with schema over a ZeroMQ channel. At each end you get a parser/generator, full schema validation and portability guarantees. XSD is just a contract specification for this. JSON and XML markup - meh.Conveniently you can visualise the data using XSLT at the debugging step as well as the thing will pop out a DOM which you can apply a transform to.It’s a construction kit, not a markup language.

author: Berni
author_rank: Super Contributor
timestamp: January 29, 2018, 06:40:06 am
content: While i prefer doing things low level, but i still think that JSON is a pretty good idea.Obviously its not for everything. If are encoding raw wave audio you probably want a binary format for its tight packing efficiency. But if you wanted to package some metadata to embed into the audio file you could certainly use JSON to encode the data and then stick than on the end or beginning of your file. The metadata is probably mostly strings anyway and there are at most kilobytes of it, not megabytes. Because JSON brings its own structure means you don't have to define a strict spec of what goes where as you do in binary. Okay you might start off with having a "Title","Artist","Genre" field, but then a mediaplayer comes along and wants to also keep volume normalization info. This was never in the spec but can simply be thrown in to the JSON anywhere you want since other apps won't be interested in it. So you just make up a field called "VolumeNorm" and give it a value of "0.443"Since things are ordered and named in there means the audio player can also have a file properties window that shows all this data in tree form. All of it is still perfectly human readable even if a file has some weird metadata fields that nobody else uses.On top of it all the JSON format is reasonably easy to encode and decode as it only adds a few extra characters into the data and you only need to keep track of where the brackets begin and end. Yes it does have to use ASCII for everything but it wouldn't be easily human readable otherwise. Pretty much all web technology uses ASCII anyway, even when its for communication between two computers: HTML HTTP XML CSS SQL etc.Yeah you still don't want to use JSON to communicate between two MCUs over a cable or radio link or something, but when you have complicated data structures that don't have a precisely defined structure then JSON is the way to go. Plus you can just copypaste the parser for it from someone else to save time. EDIT: Oh right its 2018. I meant to say "include the parser from the framework"

author: IanMacdonald
author_rank: Frequent Contributor
timestamp: January 29, 2018, 07:15:36 am
content: The problems with JSON are its fragility (any one punctuation error wrecks the lot) and that list items have to differ in syntax depending on their position in the list. A sensible design allows for all items to have the same syntax, for example in css:img {display:block;position:relative;}If you remove thepositionvalue, this does not affectdisplay. This is a good design, In JSON, removing an item from the list affects the punctuation required on the preceding item IF it was the last item, but NOT if it wasn't the last item. This is an extremely bad arrangement, especially as in large nested lists it can be hard to tell if a given item is the last one in its section.var jason = {"age" : "24","hometown" : "Missoula, MT","gender" : "male"};XML is more robust (a missing closing tag is easier to detect) and doesn't suffer the 'Last item must differ from rest' problem.

author: paulca
author_rank: Super Contributor
timestamp: January 29, 2018, 09:32:29 am
content: I fail to see the difference. A syntax error in JSON produces a syntax error. A syntax error in XML produces a syntax error. A syntax error in a binary protocol produces an obnoxious error or a seg fault depending on who wrote it.Besides this is just the separator pattern.sep=""foreach( item in list ):output( sep+item );sep=", "or just (in some languages)strOutput = join( list, "," )Anyway, all this is "different carts for different horses", each format has it's strengths and weaknesses.Personally my bug bear with XML was just how prevalent it became with everyone and their dog doing everything and the next in XML when there really was no need. I like JSON because it halted that stupidity and gave people a simpler format to put simpler things into.

author: bd139
author_rank: Super Contributor
timestamp: January 29, 2018, 10:20:06 am
content: A syntax error in JSON doesn't always produce a syntax error. We've had this a number of times. Some parsers will parse these, some wont:[ "a", "b", "c", ][ "a", "b", 'c' ][ "a", "b"There's always some clever fucker doing string manipulation at the other end or has written their own parser.

author: nfmax
author_rank: Super Contributor
timestamp: January 29, 2018, 11:07:08 am
content: Both XML and JSON have their place, which isnotthe same, and there need be no 'war' between them. JSON is now defined in RFC 8259https://www.rfc-editor.org/info/rfc8259, whichrequiresUTF-8 encoding. Tim Bray relates the history of this document, and its predecessor RFC7159 athttps://www.tbray.org/ongoing/When/201x/2017/12/14/RFC-8259-STD-90, including his part in the process. Incidentally, Tim was one of the original authors of XML (and also produced the annotated XML spechttp://www.xml.com/axml/testaxml.htmwhich I heartily recommend).Both XML and JSON compress well using standard file compression tools. Indeed, compressed XML is now pretty much the industry standard for document formats. Both Libre Office & Microsoft Office use compressed XML. Some tests I carried out a few years ago showed in fact that compressed XML wasmorecompact than an alternative 'binary' file format for the numerical data we were storing.JSONata (http://jsonata.org) is an emerging XPath-like query language for JSON, which will should to reduce the need for home-grown JSON tooling.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 29, 2018, 12:13:04 pm
content: When there's a syntax error it's always better to err than to "try to fix it" automatically.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 29, 2018, 12:36:38 pm
content: The battle between XML and JSON will go on forever...On one side of the battlefield are the application builders and back-end guru's defend their hardfaults, while on the other end the javascript framework hipsters fight for their "lightweight" collection of bugs.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 29, 2018, 12:41:18 pm
content: I remember well the conversations in the ietf mailing list when that was being discussed/written and Crockford got totally fed up with the ietf guys, and rightfully so, the result being that he decided to publish the true specs of his invention at ECMA:https://www.ecma-international.org/publications/standards/Ecma-404.htmthe #404 is a pun (intended).I've just now been trying to read those blog posts of Tim Bray but as there's lots of BS in them I've quit.

author: nfmax
author_rank: Super Contributor
timestamp: January 29, 2018, 12:46:12 pm
content: From the current ECMA spec:Quote(there may be, however, semantic differences)

author: paulca
author_rank: Super Contributor
timestamp: January 29, 2018, 12:47:09 pm
content: Quote from: GeorgeOfTheJungle on January 29, 2018, 12:13:04 pmThat's a bit absolute. I can think of many use cases where making an effort to work around errors is more appropriate.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 29, 2018, 01:26:08 pm
content: The effort has to be on the side that's generating incorrect JSONs, not on the receiving end.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 29, 2018, 01:32:51 pm
content: Typical example: {"command": "no-op", "user": "the-president", "command":"launch-missiles"}, how do you fix that?

author: Berni
author_rank: Super Contributor
timestamp: January 29, 2018, 01:46:56 pm
content: That depends on who you ask:But my point was not that JSON is better than XML. Just that sometimes there is a good reason for using JSON rather than the space efficient raw binary encoding. XML also does everything that JSON can, it just looks different.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 29, 2018, 02:16:44 pm
content: I hate XML because I hate SOAP and Dave Winer too for having to do with its inventionJSON is a dream come true for any JS programmer, more so when you're running JS both server and client side. I understand it has less appeal and there may be a noticeable impedance mismatch if you're programming in other languages, as in say, C for example.

author: nfmax
author_rank: Super Contributor
timestamp: January 29, 2018, 02:23:05 pm
content: Quote from: Berni on January 29, 2018, 01:46:56 pmRFC8259 says:QuoteWhile the ECMA specification says:QuoteYMMV!

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 29, 2018, 02:54:20 pm
content: Quote from: On 07/06/2013, at 19:02, Douglas Crockford wrote:

author: IanMacdonald
author_rank: Frequent Contributor
timestamp: January 29, 2018, 08:11:25 pm
content: Quote from: paulca on January 29, 2018, 09:32:29 amThe difference is that the last line of JSON must NOT have a comma. All others must. This makes it hard to write a routine to modify JSON. It means that if you want to remove an item you (a) have to check if it is the last item in its section, and (b) if it is, then go back up the chain and modify the previous one.In a well designed system, the required syntax for a given item should not depend on its position in the list.

author: John Coloccia
author_rank: Super Contributor
timestamp: January 30, 2018, 12:32:42 am
content: Quote from: paulca on January 28, 2018, 07:56:03 pmWell, of course you don't do that in the general case, any more than ICs sending C source code over SPI.

author: paulca
author_rank: Super Contributor
timestamp: January 30, 2018, 08:08:11 am
content: Quote from: IanMacdonald on January 29, 2018, 08:11:25 pmThat's most languages out the windows then.Also, one typically does not string parse a JSON structure (or XML). One would use a parser, not Frankenstein something up. Granted some parsers will accept the trailing , some won't, good ones will give you the choice of strict or lenient with logging of warnings.

author: paulca
author_rank: Super Contributor
timestamp: January 30, 2018, 08:09:18 am
content: Quote from: John Coloccia on January 30, 2018, 12:32:42 amThat's not really the same thing. A better analogous data structure would be a serialized C struct, which they do indeed often send over I2c/SPI.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 30, 2018, 08:28:48 am
content: Software is stupid, programmers are overpaid poetsfighting about JSON versus XML.Poor INI file, feeling all excluded.

author: bd139
author_rank: Super Contributor
timestamp: January 30, 2018, 08:34:40 am
content: You say that facetiously but I have seen a piece of software use ini files for data exchange. Not only that they were windows codepage nonsense

author: IanMacdonald
author_rank: Frequent Contributor
timestamp: January 30, 2018, 08:49:54 am
content: Quote from: Jeroen3 on January 30, 2018, 08:28:48 amINI files are actually a better arrangement from the point of view of avoiding punctuation mess, although they have the limitation of only one level of depth.You also hit a snag if a value name needs to have = in it.Agree though that the whole thing is a stupid situation, and if it had been done right from the outset then thee would have been special keyboard keys for data delimiters, characters that are not used in normal typing. Improvising led to the current mess.

author: nfmax
author_rank: Super Contributor
timestamp: January 30, 2018, 09:02:58 am
content: Quote from: IanMacdonald on January 29, 2018, 08:11:25 pmYou shouldn't be writing such a routine in the first place! Read the JSON in to create an in-memory object (using a proven JSON reader in your language of choice), modify the object, and write it out again (using a proven JSON writer in your language of choice). There are tools available to do this sort of thing. Exactly the same applies to XML or any other well-defined data serialisation format.Here is an example using JSONatahttp://docs.jsonata.org/index.html:Given the JSON:Code:{"colour": "red","age": 45,"weight": 71.08}the JSONata expression:Code:$.$sift(function($value, $key) {$key != "weight"})removes the "weight" key, returning:Code:{"colour": "red","age": 45}

author: nfmax
author_rank: Super Contributor
timestamp: January 30, 2018, 09:22:40 am
content: Quote from: IanMacdonald on January 30, 2018, 08:49:54 amASCII has a whole bunch of control codes for just this purpose :Code:00 nul 01 soh 02 stx 03 etx 04 eot 05 enq 06 ack 07 bel08 bs 09 ht 0a nl 0b vt 0c np 0d cr 0e so 0f si10 dle 11 dc1 12 dc2 13 dc3 14 dc4 15 nak 16 syn 17 etb18 can 19 em 1a sub 1b esc 1c fs 1d gs 1e rs 1f usA pity that most of them never got used

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 30, 2018, 09:38:13 am
content: I disagree, control chars are a thing of the past, invisibles are a pain in the butt, human read-ability is very a good thing. JSON is what it is: *JavaScript* Object Notation, it suits JS perfectly, for any other languages YMMV.

author: paulca
author_rank: Super Contributor
timestamp: January 30, 2018, 09:43:45 am
content: Quote from: GeorgeOfTheJungle on January 30, 2018, 09:38:13 amAgain it depends on what you are doing. Binary protocols or ASCII containing nulls and soh are common in certain circles for a reason. Also if your editor doesn't show and allow the editing of low ASCII values then you need to use a better editor.Consider:https://en.wikipedia.org/wiki/Financial_Information_eXchange

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 30, 2018, 09:49:00 am
content: Yes, my editor can show invisibles, in some languages whitespace is significant and some protocols use control chars... because the world isn't perfect

author: bd139
author_rank: Super Contributor
timestamp: January 30, 2018, 09:49:28 am
content: FIX is a nice protocol actually. It defines message length up front. This allows you to segfault shitty remote implementations. Also the header part usually gets read into a fixed buffer which can be fun. Never fucked up a broker before honestly)If you're using protocols like this, tcpdump and hexdump are your friends.

author: FrankBuss
author_rank: Unknown
timestamp: January 30, 2018, 09:57:32 am
content: Quote from: dryjoints on January 21, 2018, 06:20:12 amWell, it is not that negative. The article tries to describe ways out of the complexity of software and how it can be more reliable.One thing is more interactive programming, as Bret Victor describes in his talk, which is cited in the article, and which I already knew. Look at 10:20 in this video to see the Mario example:Would be really helpful, if normal IDEs would support this "God view" mode.Another interesting project is TLA+, which i didn't know until now:https://en.wikipedia.org/wiki/TLA%2BAmazon used it to prove and fix their software, and Microsoft has used it as well, might be a good idea to take a look at it. Now the question is, is it possible that just from such a formal description of a system, the computer can write the program that fulfills it itself?

author: paulca
author_rank: Super Contributor
timestamp: January 30, 2018, 10:01:14 am
content: Quote from: bd139 on January 30, 2018, 09:49:28 amThou shalt not segfault in stock exchanges! Segfaults cost millions a minute. Failing over can take a few minutes. Usually we would just kick the broker connection out on error, regardless if it was his error or ours.I estimate around a least a trillion dollars has passed through my code. I have also, by proxy, been in the news, which turned out NOT to be my fault, but I was in the firing line via project ownership.I'm sure the surveillance filter in work here just turned my way.

author: bd139
author_rank: Super Contributor
timestamp: January 30, 2018, 10:10:11 am
content: Quote from: paulca on January 30, 2018, 10:01:14 amYes indeed. However traders get complacent particularly when there's a fresh supply of crack and hookers. I got some contract work in to break their shit and keep them on their toes for a couple of months. Job title "wrecking ball". That place was interesting; everything was ASN.1 DER internally. Rather like ASN.1 and have used it since encapsulated in ZMQ.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 30, 2018, 10:20:45 am
content: I want a job like that!

author: Marco
author_rank: Super Contributor
timestamp: January 30, 2018, 10:23:44 am
content: Quote from: GeorgeOfTheJungle on January 30, 2018, 09:38:13 amI guess you mean control characters you don't like then. I wish control characters were a thing of the past ...Human readability is fine by me, human editability using text editors isn't worth it except in tiny niches. Which obviously doesn't include content description and database querying. Every object should have it's length encoded, humans and their pre-occupation with using decades old editors is yet another trillion dollar mistake.

author: bd139
author_rank: Super Contributor
timestamp: January 30, 2018, 10:36:57 am
content: Just a point; if it's a wire format, you really should write a wireshark protocol dissector. That makes stuff VERY easy to work with:

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 30, 2018, 10:37:01 am
content: Quote from: Marco on January 30, 2018, 10:23:44 amThere are lots of document DBs and key/value DBs and nosql DBs out there with a pure/plain text interface.

author: Marco
author_rank: Super Contributor
timestamp: January 30, 2018, 10:38:57 am
content: Quote from: GeorgeOfTheJungle on January 30, 2018, 10:37:01 amYes and that's why after SQL injection we now also have NoSQL injection ... this just goes back to the original subject of the thread.

author: netdudeuk
author_rank: Frequent Contributor
timestamp: January 30, 2018, 10:54:48 am
content: Quote from: dmills on January 21, 2018, 09:31:14 amMake that 32K

author: paulca
author_rank: Super Contributor
timestamp: January 30, 2018, 10:58:18 am
content: If you try and tell the young people of that today....https://en.wikipedia.org/wiki/Four_Yorkshiremen_sketch

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: January 30, 2018, 11:01:20 am
content: Quote from: netdudeuk on January 30, 2018, 10:54:48 amAnd 2MHz

author: John Coloccia
author_rank: Super Contributor
timestamp: January 30, 2018, 11:35:13 am
content: Quote from: paulca on January 30, 2018, 08:09:18 amIt's exactly the same thing. In both cases you're trying to send the description of something instead of the something.

author: tggzzz
author_rank: Super Contributor
timestamp: January 30, 2018, 12:28:19 pm
content: Quote from: netdudeuk on January 30, 2018, 10:54:48 amThe first computer I made had 128 bytes, because that's all I could afford and it was sufficient to prove principal.The first commercial computer I used had an architectural limit of 8k words of 39 bits each.

author: InterestedTom
author_rank: Regular Contributor
timestamp: January 30, 2018, 01:04:21 pm
content: This is a daft thread for an Electronics Community Forum. I don't think for one second you would happily live without software or you would be doing it already.

author: technix
author_rank: Super Contributor
timestamp: January 30, 2018, 06:47:35 pm
content: At least from what I feel in China it is not the programmers that should be blamed but the managers and shareholders. Programmers are often told to implement features to specification before corresponding deadlines and that is it. Programmers are often forced to sit in offices for 72 hours or more a week even when they don't have anything to do at hand to "show respect to the managers." Programmers' opinions are not taken in the decision making progress. Decision makers' understanding to the technology is often questionable. If you listen into the decision making meetings, quality control often comes last. Decisions and deadlines are often made before practicality or cost is determined, and programmers are expected to come up with snake oil if practicality is questionable, or take the blame when the project is overdue or over budget.

author: IanMacdonald
author_rank: Frequent Contributor
timestamp: February 01, 2018, 09:22:20 am
content: Quote from: GeorgeOfTheJungle on January 30, 2018, 09:38:13 amIf human readability is a requirement then we should be writing meaningful words as delimiters, not bracketbracketbracketbrackebracketbracket...also, who starts a sentence with a lowercase letter because the word can only be written that way, or walks into an office and announces. "CAPITALGEE-ood morning, CAPITALEMM-argaret!"Answer, nobody. So, why do we have to address computers in mangled grammar?Perhaps we should introduce font sensitivity into programming, where the Courier word has a different meaning from the Arial version.

author: Jeroen3
author_rank: Super Contributor
timestamp: February 01, 2018, 09:30:10 am
content: Quote from: GeorgeOfTheJungle on January 30, 2018, 09:38:13 amThing of the past is a bit bold. Shells still rely on them.And they're nice when interfacing with a little embedded device over uart. It's lightweight and a human is still able to decode the datastream.

author: paulca
author_rank: Super Contributor
timestamp: February 01, 2018, 09:33:50 am
content: Quote from: IanMacdonald on February 01, 2018, 09:22:20 amBecause it is a prescriptive 100% definitive logical and mathematical communication where no ambiguities can be tolerated. There is no "Oh I see what you mean there"They didn't just pull this stuff out of their ass you know.Take a look at COBOL. (Excuse my bastaradization it's been decades since I used it)DIVIDE 7 BY 3 GIVING REMAINDER X ANSWER YIt's verbose, cumbersome and we are not writing programs for children (business users), we are writing code for people with a (hopefully) solid understanding of engineering, what is going on and computers and logic.You don't see mathematicians writing out their equations like the COBOL syntax above either!

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: February 01, 2018, 10:12:19 am
content: Quote from: Jeroen3 on February 01, 2018, 09:30:10 amI think they're ok for binary formats, when the bytes are ~ the data rather than a representation of the data, e.g. a 0xff byte rather than a "255" string, but if you take the trouble to use a textual human readable representation of something why would you want to litter it with invisibles? The less invisible invisible is CR, and even that has problems: is it a CR? An LF? Both? If both, in which order? Grrr, no, please.

author: bd139
author_rank: Super Contributor
timestamp: February 01, 2018, 10:21:55 am
content: The answer is that a line ending is \n. Everyone else is wrong

author: lundmar
author_rank: Frequent Contributor
timestamp: February 01, 2018, 10:43:46 am
content: Having reviewed this thread I think it is safe to conclude that programmers are indeed poets

author: Kjelt
author_rank: Super Contributor
timestamp: February 01, 2018, 10:45:52 am
content: Naaah in the end we conclude that programmers are extremely smart engineers that despite many difficult and almost impossible obstacles,still are able to get things to work

author: Kjelt
author_rank: Super Contributor
timestamp: February 01, 2018, 10:51:27 am
content: The biggest problem for SW engineers is what's between the chair and the keyboard.A user can think of so many illogical input that it is impossible to prevent everything.If a HW engineer would face the same problem than it would have the enduser to allow to choose and use its own power supply,so the device you have to build has to withstand every possible powersupply with every possible connection ever made from 1,5VDC to 2kV ACAnd to proof this I have a real life situation from a friend that bought an american apparatus on amazon, it was delivered at his home with a 120V mains connector so it would not fit.The supply was 5V 2A polarized and he did not have this so he used another adapter he had lying around, his argument: the connector fitted.This was unfortunately an 14VAC adapter and the magic smoke escaped.Now who is at fault here?If this was software that failed on some stupid input everyone would point to the software engineer, now it is hardware and everyone points to the user.But was it so much extra effort to add one crowbar or one diode and fuse?Or why do we not design a special unique connector for each and every possible voltage and polarity, so grandparents and technical deficient persons can not make any mistakes ?

author: JPortici
author_rank: Super Contributor
timestamp: February 01, 2018, 10:56:54 am
content: Quote from: IanMacdonald on February 01, 2018, 09:22:20 ambrillantuse italic to comment something, underline for time-critical stuff. This is truly the language of the future

author: dmills
author_rank: Super Contributor
timestamp: February 01, 2018, 11:59:08 am
content: Oh Ghod, reminds me of something seen at university, a guy had seen the rest of us using some random syntax highlighting editor but did not really get it.He was seen to be writing a program in MS WORD, highlighting keywords in colour by hand!He did not last long on the course.Regards, Dan.

author: Maxlor
author_rank: Frequent Contributor
timestamp: February 01, 2018, 12:41:09 pm
content: Quote from: IanMacdonald on February 01, 2018, 09:22:20 amBecause you want computers to do what you say, exactly, 100% of the time. Human communication doesn't require strict grammar, because it's usually perfectly ok to go "What did you just say?" and ask for clarification. If computers did that 1000 times a second, just because the programmer used ambiguous wording, well, it wouldn't be an improvement.

author: bd139
author_rank: Super Contributor
timestamp: February 01, 2018, 12:42:04 pm
content: Quote from: dmills on February 01, 2018, 11:59:08 amThat's not as crazy as it sounds. I designed a product that uses word and control controls as in input format for tooling. This made me half my mortgage

author: paulca
author_rank: Super Contributor
timestamp: February 01, 2018, 12:49:46 pm
content: Font face, style, size etc. IS used in software to denote certain different things. But only in UML diagrams and spec docs.