|
charlieg wrote: Python has no business being in an embedded environment in any serious role.
The video did its job.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
good morning. My eyes are still watering.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Python does that to me too.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Gack, I can't even imagine considering using Python for embedded work. About the only interpreter-ish language I'd consider for embedded work is Forth. I'd worked a bit with the guys from Forth Inc. years ago and they seemed to do a lot of embedded stuff with their version of Forth. The majority of my embedded career was C/C++. Pretty much every processor I worked with had a C/C++ compiler available.
|
|
|
|
|
Quote: My problem with Python is I believe that all my source code should be visible to the naked eye. Python breaks that rule by making whitespace part of the source code. That inspires violence in me. So I don't use it.
Could not be in more agreement.
FormerBIOSGuy
|
|
|
|
|
jana_hus wrote: If it is so popular, why it needs "updating / upgrading " ? It doesn't. But then you have not explained what these "Python activities" are doing.
|
|
|
|
|
Why do runtime engines for long-established languages and frameworks get updated on every Patch Tuesday (in the case of software running on Windows)?
|
|
|
|
|
jana_hus wrote: If it is so popular,
Myself I prefer oatmeal raisin cookies. So why are there so many different varieties of chocolate chip?
|
|
|
|
|
Lots of libraries, good for non-programmers to solve problems for academia, IT folks to automate stuff, non-programmers to program and programmers to do one off stuff. The AI stuff done by Chris uses python because there is a lot of image AI stuff available. I would guess that his alternative is a lot of time spent with C++ or C# or assembler. Don't know. I do know it works very well with BlueIris.
I automated some backup stuff via a python script that uses robocopy to copy stuff to NAS and removable, sends emails based on results and then uses powershell to eject the removable. Why would I want to use something else? Well, most of it was done previously with VBScript.
If you decide to hate python, you can easily jump all over the white space thing and the rules for tabs and spaces (piling on is fun). If you just want to solve a problem, you don't care. I tested some scripts for syslog servers, then converted to C# with some GUI. Handy and easy with all the libraries.
Haters will hate, fanboys will worship, the rest of us just use whatever tool we think will get the job done. Applies to everything.
Well, I did hate Fortran back in the day.
>64
It’s weird being the same age as old people. Live every day like it is your last; one day, it will be.
|
|
|
|
|
It is strange how different people feel about programming languages - I actually liked my programming time with COBOL
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
ewww, that's gross. NSFW.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I wrote two COBOL programs in my life. They earned me a top grade on the COBOL exam. (At that time, Norwegian universities used a character scale from 1 to 6, with 1 corresponding to an 'A' - I got a 1.)
The programming exercises through the COBOL course was not mandatory, and I didn't do a single one of them. But I did study the language, without practicing it. I also suspect (my memory is a little rusty) that this was an open book exam.
In my archives, I have a photocopy of the preface to the COBOL-60 standard. It states that with COBOL, there is no longer a need for specialized training in programming. You just write down the operations to be performed in a slightly formalized English. 20 years later, that gave us a good laugh, but there is a point to it: You could understand a lot of the program logic without a PhD or Master in programming. Maybe not even a Bachelor! In a code review, even an accountant worker or warehouse worker might object: But that is not how we do it! - whether referring to calculations or flow.
Even C was far less readable for a non-programmer than COBOL was. And modern C++ code is almost impossible to read even if you have a Master or PhD in programming. That's how we want it! COBOL didn't have the qualities required for a tribal language, comprehensible only to the initiated ones. C++ does.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
what you just wrote is priceless historical knowledge. I mean that sincerely.
I was deep down in the bowels of a system I inherited that just did not work. The COBOL code had to call a C routine to interface with ACMS (we're back to Digital Equipment). Damn code would not work. Then I realized the COBOL code was passing a "1" as an ascii "1" and not 0x01. This happened: Man destroys computer - YouTube[^]
IT comes down to understanding the system and the background, so I agree with you.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
theoldfool wrote: Lots of libraries, good for non-programmers to solve problems for academia, IT folks to automate stuff, non-programmers to program and programmers to do one off stuff. As if that is something particular to Python?
When you have to go outside the language itself to defend it, then I start questioning the language qualities. Isn't the language itself the essential when evaluating a language? It is OK after pointing out seven essential qualities of the language, not commonly found in other languages, to add: 'Besides, the ecosystem around the language is really strong, with lots of good languages'. Without stating a single unique (or rarely found) quality of the language itself, I might as well go looking for other ecosystems, preferably those adapted to several languages.
It reminds me of the old Internet stack - OSI stack wars, essential in the 1990s: Neither during the network wars nor later have I found any person willing to argument in favor of the qualities of the Internet protocols as such. Sure, it was more widespread. Sure, you could get the specs for free. Sure, half of the protocol acronyms started with 'S', for 'Simple', suggesting that if a 3rd year college student couldn't implement it as a homework assignment, then the feature was not included in the protocol. (That has changed in recent years, though - there are reasons why TCP is provided with the OS!) Lots of other ecosystem arguments were brought fort in favor of Internet, but never the quality of the protocol design.
I like dotNET for being language agnostic. You can create a library in any language for which there is a dotNET compiler - and that compiler is independent of the CPU, instruction set, addressing modes etc. An voila! The library is available for any other dotNET application development, regardless of programming language!
A small reservation: As far as I know, Python is available for dotNet. I wouldn't at all be surprised if it requires its own Python libraries and cannot utilize standard dotNet libaries. That would be in the typical Python style - Python people traditionally insist on having their own sandbox, completely unwilling to make adaptions to the myriad of great libraries out there, and doing nothing to make these allegedly super great Python libraries available to anyone else. If you want to play in our sandbox, you must play Python, or get away from us and our sandbox!
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
I wasn't trying to defend anything. Just expressing my opinion and usage.
Like I said, the haters will pile on.
>64
It’s weird being the same age as old people. Live every day like it is your last; one day, it will be.
|
|
|
|
|
Please note that there is an ocean between criticism and hate. I claim my full freedom to criticize both Python and other phenomena, without being called a 'hater'. (I know of nations that accept no critical remarks to their foreign policy, without labeling as 'hate' of the population of the nation, but here, we should try to act as professionals and accept disagreements. I even claim my right to dislike some phenomenon without therefore being labeled as a 'hater' of it.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
If professionals cannot have a heated argument or debate, we are doomed. It's how stuff gets done. Otherwise, we have meetings into mediocrity and stuff blows up. We don't need any more facilitators, we need boxing gloves.
I like your attitude.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
trønderen wrote: When you have to go outside the language itself to defend it, then I start questioning the language qualities.
By 'qualities' do you mean syntax? Or something else?
|
|
|
|
|
How far do you draw 'syntax'? Lots of aspects are consequences of the syntax, but can be identified as distinct qualities of their own - and if you like, you may reply: But that is just syntax!
Let me pop a few elements off the top of my head:
'Readability': Semantics are easily discernible from the printed representation. 'Easily' here means that you need as little background study as possible to understand the symbols to see their meaning. You can discuss a COBOL program with an accountant, but probably not a C++ program to perform the same task!
'Explicitness': The source code should make those elements (conditions, actions, ...) that are significant to the application solution stand out clearly, without drowning in red tape, irrelevant (to the problem solution) punctuation and other 'noise' mandated by syntax.
'Naturalness': Established linguistic elements should as far as possible retain their established semantics when adopted by a language. This in particular applies to keywords - if you use another term when explaining the code to a non-programmer than the keyword, then the keyword is poorly chosen. Similar applies to all sorts of punctuation; they should have the established meaning.
'Consistency': Doing similar operations (e.g. on different data types) in similar ways. Doing identical operations in different implementations gives identical results.
'Unambiguousness': Preferably in a 'natural' way, so that a minimum of 'unnatural' syntax is required. (Take parenthesizing of logical conditions: Lots of languages follow natural languages, with no parentheses, other languages have a syntax that would be ambiguous without them.)
'Conciseness': To obtain a certain well defined effect, a single syntactic element should be required to invoke it. For more complex effects, a minimum of syntactical elements should be required.
'Safety': Errors that could be detected before the program is run should be detected before the program is run. If an error
occurs at run time, it should have minimum disastrous effects.
'Environmental friendliness': If a partial solution is available from outside, it should be possible to adapt it as part of the total solution, with as few limitations (e.g. to the implementation language of the imported module) as possible. It should be possible to develop partial solution in this language for use in other total solutions, even if they are developed in other languages.
'Completeness': The basic mechanisms (data structures, flow, synchronization, ...) should be as complete as expected by the application domain. E.g. in an engineering oriented language, it shouldn't be necessary to construct your own complex type. In a business oriented language, fixed point types and arithmetic should be available.
'Suitable data types': Especially for domain specific languages, the basic data types of the language, as well as the mechanisms for building complex objects, should match the established domain concepts as closely as possible. E.g. APL objects closely matches the concepts for which the language was developed - matrix manipulation - while lisp object do not.
'Orthogonality and simplicity': To the extent possible, there should be one way of doing things rather than several similar but not identical ways of doing almost the same thing. A mechanism should be available in all contexts unless conceptually meaningless.
'Strictness': As opposed to 'forgiven-ness'. If you program something in a dubious way, the language should not gloss it over, but tell you. Rules are to be followed.
'Abstraction level': Basic mechanisms should be at an abstraction level that reasonably matches the level of the problem solution. E.g. a binary semaphore belongs at the assembly level of synchronization; critical regions and monitors are closer to the level of application problems.
'Adaptability': No construct should make adaptations, such as internationalization, difficult or impossible. E.g. there should not be restrictions on the characters in strings.
Difficult to make mistakes: Some languages are known for their 'You asked for it, you got it' nature: Constructs are 'legal', you receive no warning even if there is a 95% probability that you meant to write something else. The language should, as far as possible, provide an error/warning when you do something dubious, such as making assignments or expressions with differing types.
If you ask me again tomorrow, maybe I will can add another half a dozen of points
You may of course say that all of the qualities I identify above boils down to 'syntax'. That doesn't get us much further in creating better languages, 'We need a better syntax'. The list above is an attempt to clear away some of the fog, so we can more clearly see what we want to achieve with a better syntax.
Disclaimer: The list above was written down in a few minutes; it is not the result of any thorough analysis or evaluation. So it is most certainly incomplete. Maybe some will say even inconsistent in a couple places, but I think that depends on who is reading it.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Maybe I misunderstood your intention. Did you mean to ask about those elements that are distinct from the language and itself, but is part of the ecosystem in which the language is used?
I certainly may value the qualities of an ecosystem. As I mentioned in another post: The dotNet ecosystem allows you to develop different modules (for the same end result) in different languages; you pick the one best suited for the task. E.g. defining a dialog layout is a lot easier in the XAML language than in C#. That is an ecosystem quality, regardless of the qualities of XAML or C# as two of the languages in that ecosystem.
Availability of well known, well tested, highly recognized libraries is most certainly a positive quality of an ecosystem - more strongly, of course when the library functions you need are provided. Libraries are examples of reusability, which is a positive quality, and if a library is reusable across a large family of languages, that raises its value.
Having the option to study the inner workings of a library function, e.g. through the source code, may represent a positive value to some user groups.
Having the option to close your solutions' inner workings may represent a value to some user groups. So may the option to e.g. sign your solutions, protect use of them with a license key etc. - but note that this may conflict with other qualities.
A high quality development environment, with good editors, debuggers, test facilities, library management facilities etc. is also an important ecosystem quality.
The support availability and quality is an important quality. Qualifications for giving good support includes the ability to talk the customer's language, and understand his problem. Good documentation that can be easily understood by the target group, is a part of support quality of the ecosystem.
And then you have those ecosystem properties that may be qualities or dis-qualities. The general helpfulness of people using a certain ecosystem does have an effect on my perceived quality of the environment.
So, if you have an excellent ecosystem with all of these qualities at a high level, can you then throw in any programming language, regardless of how rotten the syntax is, with rock bottom score on most of the language qualities I listed in my previous post? Well, you may try. It may seriously degrade the users' perception of the ecosystem qualities, if the pure coding part sets them bitching and swearing.
That goes the other way, too: An excellent program language definition may suffer if the ecosystem surrounding it is rotten. Especially if you are bound to using one specific ecosystem and cannot replace e.g. the editor, cannot use libraries from other sources etc.
Both the language definition and the ecosystem must be of 'sufficiently high' quality. What is sufficient, depends a lot on context. Some qualities super-essential to one developer may have no significance to another one.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
I second this.
Python scripts are easy enough to write and quick enough to execute that we can iteratively automate stuff that would not otherwise be automated. Because Python libraries are available to do almost everything, we now have a series of Python-based solutions where previously we had C, C++, Java and even Pascal.
|
|
|
|
|
Python is popular because
- it is user-friendly: tab vs. space is matter of life and death, case sensitive, uses == as 'equal'
- it is finance-friendly: no fixed-point datatype
|
|
|
|
|
"finance-friendly" - thought for sure you were going to say "free."
honestly though, when I saw that tab/space meant different things, I just moved on. Kiddie language, but that's just me.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Funny enough, I find myself asking this EXACT same question this morning.
I checked in on a start-up project I'm part of, and noted an eMail from the "Cellular Modem" developer we have working out the AT commands required to talk to MS-Azure.
Over the course of the past 3 weeks, I personally have built and put in place a modem framework in our IoT application code base. I have provided EVERYTHING needed from turning certificates into byte arrays, and providing methods to load, unload them, I have provided a comprehensive framework that allows AT strings to be sent to and the answers received back from the modem easily.
I have EVEN compiled that code into a PC/X86 library and with the aid of a console mode program running under visual studio, it can be used to send and receive AT commands, work with certificates and everything else needed, using exactly the same API on a PC, with the modem connected via a USB to serial cable.
The "Modem Developer" has spent all day last Friday, making his OWN serial cable for the modem board, writing a Python library to drive that serial cable using his own Python based "development tools", and he has made a new python test suite that allows him to send string to the modem, get the answers back, and hit a button to make the python code generate new C code that interfaces with my API.
When asked why...
"Beacuse I find it easier", came his answer...
:-S
So it was easier for him to build an entirely new Python layer on top of the work I'd already done, instead of just typing in AT strings into a console mode app in V-Studio and hitting Ctrl+Alt+B to compile it, then F5 to run it???
I really, really, really just don't get it either.
If I was starting from scratch on a PC, and doing this testing then yes, maybe... but I'd still use the standard serial access libs, and an already provided USB to Serial cable (Which we provided to him in the box with the modem board), I wouldn't take an FT232H write my own user mode WinUSB driver for it, invent my own protocol, wire it up to a MAX232 so I could connect to a normal RS232 9PIN connector, then write my own framework around it, then write a code generator to generate C code on top of that!! That's just plain madness.
So yes, sigh.... I find myself asking the same question.
|
|
|
|
|
this is not a python problem. Where's the boss?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|