Quote from dandl on February 9, 2021, 12:53 am

Quote from Dave Voorhis on February 8, 2021, 9:49 am

Quote from dandl on February 8, 2021, 5:07 am

Yes. This is the Access version of exactly the process I have in mind. So, at a more abstract level, the process is:

1. Create a series of documents representing the database, relationships, grids, forms, reports and queries that constitute 80% of the application
2. Write code snippets in some GP language for the other 20%.
3. Integrate the two (Access uses COM but there are better choices).

I spent a little time with Access (it's been a long time) and yes indeed, it's the same  model. Right across the top you can create tables, queries, forms (grid and item), reports and code. It's rather heavy on the UI visuals (as you would expect), but it certainly seems able to satisfy my Proposition 1.

Does it use COM?

I've never noticed. From an Access point of view, that's completely in the background and invisible to the user/developer.

Not really. The Component Object Model is totally based on objects and comes with a particular type system. There are things you can't do easily, and it doesn't set well with other GP languages such as Java or even C#. The same language works right across Office precisely because they all expose a COM model. You have to buy into a particular narrow set of technologies to be comfortable with Access, I think.

It plays well with the rest of the Office suite, which if you're using Access is probably what you want more often than not.

Which is why a similar product unconnected with Office or MS might have a place.

I have, by the way, a fair bit of familiarity with Access. In the 1990s, my company developed what was -- as we were told by one of the Microsoft developers on the Access team, that was as far as he knew -- the largest bespoke application written in Access. It had a relatively small number of tables (by enterprise standards) at only 170 or so, but queries, forms, and reports each numbered in the thousands.

Typical Powerflex applications are of roughly that size. I know of at least 4 customers with over a million lines of source code, which would typically equate to a thousand or more little data entry forms and reports, plus a few large forms and batch processes. I know the space well.

Which begs the question: is it alone on the island? Are there are any other products that can do this exact thing, without being tied to these specific technologies? There are lots of people out there who say then can, but really?

Over the years, I've seen the "is there anything like Access" question come up a lot, even going back to the very early days of Access 1.0 in 1992. A bit of probing would often reveal that the question was actually, "I've been given an .mdb/.accdb file. Is there anything I can use to read/modify it without paying for Access?"

The answer to that being, "No, not really."

There is a fairly well-known Java library called Jackcess (https://jackcess.sourceforge.io/) that's often used to read and write .mdb/.accdb file contents in a limited fashion (which for many purposes, is enough) but nothing I know of that does exactly what Access does, almost certainly because Access does it and does it really well. If you've got Office 365 Pro Plus -- and these days, what enterprise doesn't? -- you've got Access.

The closest non-MS desktop software is perhaps LibreOffice Base. Outside of that, there are the oodles of no-code/low-code offerings you've seen, some of which probably pre-date Access and will be around long after it's gone. Many of those are likely one-man-band efforts, perhaps surviving for decades on one or two clients. Others are more recent and fully hipster compliant (see https://airtable.com/about, which is almost a parody of a "modern" company right down to the open plan gym-style office space, vintage-bulb lighting, concrete floor, nerdy-cool young people, and office dog.)

This is not about life after Access. The brief is as per Access BUT with modern twists:

• start with nocode, add snippets, add more code as needed BUT no dependency on Office or VBA (say Java or C# or JS)
• database local, server or enterprise BUT not cloudy, I want to own and control my data, and maybe use other tools on it
• deploy to the desktop BUT also to the web (under my control)

Airtable and Knack just don't cut it. Subscription model, totally cloudy, they keep your data: you can export it, but not access it.

But back in the MS world, doesn't Sharepoint let you create data views and entry forms in an Access-like fashion, but integrates over .NET instead of COM (?)?

So, if you had a product of this kind, which roughly conformed to the Proposition 1 model and (unlike Access) was really friendly to all the tools you like, would you use it?

When it comes to that, I use Access. For the sort of things I use Access to do, it usually needs to be closer to Excel/Word than any other tools I usually use.

If I need to access Access data from other tools I set up a MS Access Database ODBC connection.

But that begs the question: what do you do if it needs to be closer to Java, and Office is not in the picture?

As I've mentioned before, the world seems to moving away from desktop data entry -- where CRUD forms dominate -- to desktop data crunching where data comes in as CSV/XLSX/Web-scrapes, gets visualised and queried, and exported as CSV/XLSX. For that, Access is adequate but not very agile. I use Rel for a lot of that (it too is adequate but not very agile), and I see a lot of other people using Python.

I agree, my primary use case is a mixture: lots of imported datasets and a bit of manual data entry to tie it together. Not just visualisation, but data wrangling.

A lot of end-user, technically-savvy-but-not-a-programmer types who would have used BASIC or dBase in the 1980s and VB and Access/Excel VBA in the 1990s / early 2000s have leapt onto Python like hungry beasts on steak. It hardly seems like the most efficient or effective way of doing things, but for the sort of people that do this sort of thing I suspect they're more motivated by the fun of being an end-user programmer than anything else.

Python is crap for this. Python is a fantastic glue language, largely due to the efforts of Mark Hammond (whom I know), but it's a code-first solution. Even Jupyter is really just an IDE for Python code. It's totally closed to people who just want to wrangle data and not write code.

So how about it? Access for Java?

 

 

Quote from Dave Voorhis on February 9, 2021, 12:27 pm

Quote from dandl on February 9, 2021, 12:53 am

Quote from Dave Voorhis on February 8, 2021, 9:49 am

Quote from dandl on February 8, 2021, 5:07 am

Yes. This is the Access version of exactly the process I have in mind. So, at a more abstract level, the process is:

1. Create a series of documents representing the database, relationships, grids, forms, reports and queries that constitute 80% of the application
2. Write code snippets in some GP language for the other 20%.
3. Integrate the two (Access uses COM but there are better choices).

I spent a little time with Access (it's been a long time) and yes indeed, it's the same  model. Right across the top you can create tables, queries, forms (grid and item), reports and code. It's rather heavy on the UI visuals (as you would expect), but it certainly seems able to satisfy my Proposition 1.

Does it use COM?

I've never noticed. From an Access point of view, that's completely in the background and invisible to the user/developer.

Not really. The Component Object Model is totally based on objects and comes with a particular type system. There are things you can't do easily, and it doesn't set well with other GP languages such as Java or even C#. The same language works right across Office precisely because they all expose a COM model. You have to buy into a particular narrow set of technologies to be comfortable with Access, I think.

It plays well with the rest of the Office suite, which if you're using Access is probably what you want more often than not.

Which is why a similar product unconnected with Office or MS might have a place.

Yes, agreed. It might.

I have, by the way, a fair bit of familiarity with Access. In the 1990s, my company developed what was -- as we were told by one of the Microsoft developers on the Access team, that was as far as he knew -- the largest bespoke application written in Access. It had a relatively small number of tables (by enterprise standards) at only 170 or so, but queries, forms, and reports each numbered in the thousands.

Typical Powerflex applications are of roughly that size. I know of at least 4 customers with over a million lines of source code, which would typically equate to a thousand or more little data entry forms and reports, plus a few large forms and batch processes. I know the space well.

Of course, but presumably Powerflex was designed for that. When we were packing 170+ tables and thousands of queries, forms and reports into Access, the general assumption in the developer community was that Access was a weirdly useless product, at best suitable for people who were too dim to use Excel or too incompetent to write real applications in Visual Basic or C++. Etc.

Which begs the question: is it alone on the island? Are there are any other products that can do this exact thing, without being tied to these specific technologies? There are lots of people out there who say then can, but really?

Over the years, I've seen the "is there anything like Access" question come up a lot, even going back to the very early days of Access 1.0 in 1992. A bit of probing would often reveal that the question was actually, "I've been given an .mdb/.accdb file. Is there anything I can use to read/modify it without paying for Access?"

The answer to that being, "No, not really."

There is a fairly well-known Java library called Jackcess (https://jackcess.sourceforge.io/) that's often used to read and write .mdb/.accdb file contents in a limited fashion (which for many purposes, is enough) but nothing I know of that does exactly what Access does, almost certainly because Access does it and does it really well. If you've got Office 365 Pro Plus -- and these days, what enterprise doesn't? -- you've got Access.

The closest non-MS desktop software is perhaps LibreOffice Base. Outside of that, there are the oodles of no-code/low-code offerings you've seen, some of which probably pre-date Access and will be around long after it's gone. Many of those are likely one-man-band efforts, perhaps surviving for decades on one or two clients. Others are more recent and fully hipster compliant (see https://airtable.com/about, which is almost a parody of a "modern" company right down to the open plan gym-style office space, vintage-bulb lighting, concrete floor, nerdy-cool young people, and office dog.)

This is not about life after Access. The brief is as per Access BUT with modern twists:

• start with nocode, add snippets, add more code as needed BUT no dependency on Office or VBA (say Java or C# or JS)
• database local, server or enterprise BUT not cloudy, I want to own and control my data, and maybe use other tools on it
• deploy to the desktop BUT also to the web (under my control)

Airtable and Knack just don't cut it. Subscription model, totally cloudy, they keep your data: you can export it, but not access it.

Yes, I see an almost inevitable coming pushback against closed SaaS offerings, but it will probably take a few epically newsworthy failures for that to happen.

What's notable is that Airtable's history on Wikipedia (https://en.wikipedia.org/wiki/Airtable) features five rounds of ever-increasing venture capital, along with impressive (sarcasm) technical and business achievements like, "Airtable introduces barcode as new field type."

These are not hallmarks of success, except perhaps in obtaining so much venture funding. That is impressive.

But back in the MS world, doesn't Sharepoint let you create data views and entry forms in an Access-like fashion, but integrates over .NET instead of COM (?)?

So, if you had a product of this kind, which roughly conformed to the Proposition 1 model and (unlike Access) was really friendly to all the tools you like, would you use it?

When it comes to that, I use Access. For the sort of things I use Access to do, it usually needs to be closer to Excel/Word than any other tools I usually use.

If I need to access Access data from other tools I set up a MS Access Database ODBC connection.

But that begs the question: what do you do if it needs to be closer to Java, and Office is not in the picture?

You can access the Access database via ODBC from Java, which works quite nicely.

As I've mentioned before, the world seems to moving away from desktop data entry -- where CRUD forms dominate -- to desktop data crunching where data comes in as CSV/XLSX/Web-scrapes, gets visualised and queried, and exported as CSV/XLSX. For that, Access is adequate but not very agile. I use Rel for a lot of that (it too is adequate but not very agile), and I see a lot of other people using Python.

I agree, my primary use case is a mixture: lots of imported datasets and a bit of manual data entry to tie it together. Not just visualisation, but data wrangling.

A lot of end-user, technically-savvy-but-not-a-programmer types who would have used BASIC or dBase in the 1980s and VB and Access/Excel VBA in the 1990s / early 2000s have leapt onto Python like hungry beasts on steak. It hardly seems like the most efficient or effective way of doing things, but for the sort of people that do this sort of thing I suspect they're more motivated by the fun of being an end-user programmer than anything else.

Python is crap for this. Python is a fantastic glue language, largely due to the efforts of Mark Hammond (whom I know), but it's a code-first solution. Even Jupyter is really just an IDE for Python code. It's totally closed to people who just want to wrangle data and not write code.

Yes, Python is crap for this. But that doesn't stop people from rushing to it with great delight and eagerness.

Something that can't be discounted is the degree to which people go to effort not because it's efficient and productive but because it's fun.

In the past, a power user was a person who knew how to use software really well and effectively, but didn't program. Now a power user is typically a person who knows how to use software really well and effectively but would rather spend all day trying to code rubbishy Python scripts.

So how about it? Access for Java?

That is kind of the niche I'm trying to fill with my datasheet aka Java for Data, I guess.

Though I'd like to think it's very much not Access at all.

I want it to be better than Access, because if there's anything I learned from a decade of developing with Access is that for all the ways it's great and largely unknown for that greatness, it's also horrible in various ways. I want to avoid its mistakes, and ideally avoid the problems that made other developers shun it.

My early proof-of-concept datasheet prototype probably has more in common with Excel than Access, along with cross-platform "application"/datasheet deployability that I think is fairly unique. You should be able to run a datasheet on your desktop or deploy it to servers, so datasheets can be accessible to/via your office workgroup, the enterprise LAN, in the cloud, wherever, and link it to other datasheets that are... Anywhere.

But there are so many issues to resolve with that, too. If it works, it might be a marvel -- the basis for a web of related and relatable data -- or utter rubbish. Not sure which, but I'm aiming to find out.

I'm back to working on it steadily now, having taken almost a year break -- but for occasional half-hearted stabs -- due to life and other interests intruding.

Quote from AntC on February 10, 2021, 7:11 am

Quote from Dave Voorhis on February 9, 2021, 12:27 pm

Quote from dandl on February 9, 2021, 12:53 am

Quote from Dave Voorhis on February 8, 2021, 9:49 am

Quote from dandl on February 8, 2021, 5:07 am

 

A lot of end-user, technically-savvy-but-not-a-programmer types who would have used BASIC or dBase in the 1980s and VB and Access/Excel VBA in the 1990s / early 2000s have leapt onto Python like hungry beasts on steak. It hardly seems like the most efficient or effective way of doing things, but for the sort of people that do this sort of thing I suspect they're more motivated by the fun of being an end-user programmer than anything else.

Python is crap for this. Python is a fantastic glue language, largely due to the efforts of Mark Hammond (whom I know), but it's a code-first solution. Even Jupyter is really just an IDE for Python code. It's totally closed to people who just want to wrangle data and not write code.

Yes, Python is crap for this. But that doesn't stop people from rushing to it with great delight and eagerness.

Something that can't be discounted is the degree to which people go to effort not because it's efficient and productive but because it's fun.

In the past, a power user was a person who knew how to use software really well and effectively, but didn't program. Now a power user is typically a person who knows how to use software really well and effectively but would rather spend all day trying to code rubbishy Python scripts.

Yes, what is it with Pythoners? I've just been trying to make sense of a StackOverflow q. "My use case is in converting some Python code to Haskell, I wanted to keep the API the same but add some type safety."

For crying out loud! Haskell is not just Python with 'type safety' sprinkled on top somehow. Neither is it a thing to convert Python code to language X and keep the same API. You're going to end up with non-idiomatic code in any other language.

Matt Parker on YouTube 'Stand Up Maths' does a heap of recreational maths, and presents really well. But always he 'proves' his claims with code in Python. Pleeeease use a language with more robust semantics and type disciplines. Publishing the code (which he does) doesn't really 'keep him honest', because I suspect most viewers won't bother crawling through it. He does massive amounts of importing datasets from public sources and 'crunching the numbers'.

(Also using a Higher Level Language would be more productive, less verbose, and therefore more fun/less tedious nitty-gritty -- but I suppose that's just my opinion.)

Quote from dandl on February 10, 2021, 8:02 am

 

I have, by the way, a fair bit of familiarity with Access. In the 1990s, my company developed what was -- as we were told by one of the Microsoft developers on the Access team, that was as far as he knew -- the largest bespoke application written in Access. It had a relatively small number of tables (by enterprise standards) at only 170 or so, but queries, forms, and reports each numbered in the thousands.

Typical Powerflex applications are of roughly that size. I know of at least 4 customers with over a million lines of source code, which would typically equate to a thousand or more little data entry forms and reports, plus a few large forms and batch processes. I know the space well.

Of course, but presumably Powerflex was designed for that. When we were packing 170+ tables and thousands of queries, forms and reports into Access, the general assumption in the developer community was that Access was a weirdly useless product, at best suitable for people who were too dim to use Excel or too incompetent to write real applications in Visual Basic or C++. Etc.

It was indeed, but in another era. It started in MSDOS with 640K and ISAM with network locking, so we had a lot of ground to make up. Access was native Windows, native SQL and easily connected to real servers.

This is not about life after Access. The brief is as per Access BUT with modern twists:

• start with nocode, add snippets, add more code as needed BUT no dependency on Office or VBA (say Java or C# or JS)
• database local, server or enterprise BUT not cloudy, I want to own and control my data, and maybe use other tools on it
• deploy to the desktop BUT also to the web (under my control)

Airtable and Knack just don't cut it. Subscription model, totally cloudy, they keep your data: you can export it, but not access it.

Yes, I see an almost inevitable coming pushback against closed SaaS offerings, but it will probably take a few epically newsworthy failures for that to happen.

What's notable is that Airtable's history on Wikipedia (https://en.wikipedia.org/wiki/Airtable) features five rounds of ever-increasing venture capital, along with impressive (sarcasm) technical and business achievements like, "Airtable introduces barcode as new field type."

These are not hallmarks of success, except perhaps in obtaining so much venture funding. That is impressive.

Indeed. But VC funding is looking for the exit and that goes with A-grade customers, Fortune 500 and the like.

Something that can't be discounted is the degree to which people go to effort not because it's efficient and productive but because it's fun.

Finding bugs is not fun.

In the past, a power user was a person who knew how to use software really well and effectively, but didn't program. Now a power user is typically a person who knows how to use software really well and effectively but would rather spend all day trying to code rubbishy Python scripts.

So how about it? Access for Java?

That is kind of the niche I'm trying to fill with my datasheet aka Java for Data, I guess.

Though I'd like to think it's very much not Access at all.

I want it to be better than Access, because if there's anything I learned from a decade of developing with Access is that for all the ways it's great and largely unknown for that greatness, it's also horrible in various ways. I want to avoid its mistakes, and ideally avoid the problems that made other developers shun it.

My early proof-of-concept datasheet prototype probably has more in common with Excel than Access, along with cross-platform "application"/datasheet deployability that I think is fairly unique. You should be able to run a datasheet on your desktop or deploy it to servers, so datasheets can be accessible to/via your office workgroup, the enterprise LAN, in the cloud, wherever, and link it to other datasheets that are... Anywhere.

But there are so many issues to resolve with that, too. If it works, it might be a marvel -- the basis for a web of related and relatable data -- or utter rubbish. Not sure which, but I'm aiming to find out.

I'm back to working on it steadily now, having taken almost a year break -- but for occasional half-hearted stabs -- due to life and other interests intruding.

So I have a use case. I'm a member of an Angel investor group, and we have the usual problems:

• track members, guests and prospects
• track deals in progress
• track deals done.

We've used software specialised for the purpose, and it simply does not let us add features or wrangle the data we've got the way we want. So we've started using Knack for screening deals, and that works quite nicely. Now we want to grow that, and we'll probably stick to Knack. We have a paid account.

Access would kill it, but in this case the cloud access is the key so no go.

The guy doing this is not me, and is not a programmer. I've had a watching brief, but he's got what we need without any coding. Some snippets would come in handy, but he's definitely not going to switch to Python.

So why is he not your target market?

 

Quote from Dave Voorhis on February 10, 2021, 9:56 am

Quote from dandl on February 10, 2021, 8:02 am

 

I have, by the way, a fair bit of familiarity with Access. In the 1990s, my company developed what was -- as we were told by one of the Microsoft developers on the Access team, that was as far as he knew -- the largest bespoke application written in Access. It had a relatively small number of tables (by enterprise standards) at only 170 or so, but queries, forms, and reports each numbered in the thousands.

Typical Powerflex applications are of roughly that size. I know of at least 4 customers with over a million lines of source code, which would typically equate to a thousand or more little data entry forms and reports, plus a few large forms and batch processes. I know the space well.

Of course, but presumably Powerflex was designed for that. When we were packing 170+ tables and thousands of queries, forms and reports into Access, the general assumption in the developer community was that Access was a weirdly useless product, at best suitable for people who were too dim to use Excel or too incompetent to write real applications in Visual Basic or C++. Etc.

It was indeed, but in another era. It started in MSDOS with 640K and ISAM with network locking, so we had a lot of ground to make up. Access was native Windows, native SQL and easily connected to real servers.

This is not about life after Access. The brief is as per Access BUT with modern twists:

• start with nocode, add snippets, add more code as needed BUT no dependency on Office or VBA (say Java or C# or JS)
• database local, server or enterprise BUT not cloudy, I want to own and control my data, and maybe use other tools on it
• deploy to the desktop BUT also to the web (under my control)

Airtable and Knack just don't cut it. Subscription model, totally cloudy, they keep your data: you can export it, but not access it.

Yes, I see an almost inevitable coming pushback against closed SaaS offerings, but it will probably take a few epically newsworthy failures for that to happen.

What's notable is that Airtable's history on Wikipedia (https://en.wikipedia.org/wiki/Airtable) features five rounds of ever-increasing venture capital, along with impressive (sarcasm) technical and business achievements like, "Airtable introduces barcode as new field type."

These are not hallmarks of success, except perhaps in obtaining so much venture funding. That is impressive.

Indeed. But VC funding is looking for the exit and that goes with A-grade customers, Fortune 500 and the like.

Something that can't be discounted is the degree to which people go to effort not because it's efficient and productive but because it's fun.

Finding bugs is not fun.

It's not fun for us, because bugs slow our productivity and get in the way of delivering value.

But for the dedicated non-career Pythonista (I use the term mockingly), bugs are all part of the I'm-pretending-to-be-a-developer fun, especially if they distract you from more hateful parts of your real job.

In the past, a power user was a person who knew how to use software really well and effectively, but didn't program. Now a power user is typically a person who knows how to use software really well and effectively but would rather spend all day trying to code rubbishy Python scripts.

So how about it? Access for Java?

That is kind of the niche I'm trying to fill with my datasheet aka Java for Data, I guess.

Though I'd like to think it's very much not Access at all.

I want it to be better than Access, because if there's anything I learned from a decade of developing with Access is that for all the ways it's great and largely unknown for that greatness, it's also horrible in various ways. I want to avoid its mistakes, and ideally avoid the problems that made other developers shun it.

My early proof-of-concept datasheet prototype probably has more in common with Excel than Access, along with cross-platform "application"/datasheet deployability that I think is fairly unique. You should be able to run a datasheet on your desktop or deploy it to servers, so datasheets can be accessible to/via your office workgroup, the enterprise LAN, in the cloud, wherever, and link it to other datasheets that are... Anywhere.

But there are so many issues to resolve with that, too. If it works, it might be a marvel -- the basis for a web of related and relatable data -- or utter rubbish. Not sure which, but I'm aiming to find out.

I'm back to working on it steadily now, having taken almost a year break -- but for occasional half-hearted stabs -- due to life and other interests intruding.

So I have a use case. I'm a member of an Angel investor group, and we have the usual problems:

• track members, guests and prospects
• track deals in progress
• track deals done.

We've used software specialised for the purpose, and it simply does not let us add features or wrangle the data we've got the way we want. So we've started using Knack for screening deals, and that works quite nicely. Now we want to grow that, and we'll probably stick to Knack. We have a paid account.

Access would kill it, but in this case the cloud access is the key so no go.

The guy doing this is not me, and is not a programmer. I've had a watching brief, but he's got what we need without any coding. Some snippets would come in handy, but he's definitely not going to switch to Python.

So why is he not your target market?

He might turn out to be part of my target market, but I'm not looking at him first. First, I'm looking at me.

If it does what I want, then it's great. Job done, etc. I'm going full eat-your-own-dogfood with this, because I think it's the only way to produce something that's really usable as opposed to just ticking boxes beside requirements.

If it does what anyone else wants, that's a bonus.

Quote from Dave Voorhis on February 10, 2021, 10:03 am

Quote from AntC on February 10, 2021, 7:11 am

Quote from Dave Voorhis on February 9, 2021, 12:27 pm

Quote from dandl on February 9, 2021, 12:53 am

Quote from Dave Voorhis on February 8, 2021, 9:49 am

Quote from dandl on February 8, 2021, 5:07 am

 

A lot of end-user, technically-savvy-but-not-a-programmer types who would have used BASIC or dBase in the 1980s and VB and Access/Excel VBA in the 1990s / early 2000s have leapt onto Python like hungry beasts on steak. It hardly seems like the most efficient or effective way of doing things, but for the sort of people that do this sort of thing I suspect they're more motivated by the fun of being an end-user programmer than anything else.

Python is crap for this. Python is a fantastic glue language, largely due to the efforts of Mark Hammond (whom I know), but it's a code-first solution. Even Jupyter is really just an IDE for Python code. It's totally closed to people who just want to wrangle data and not write code.

Yes, Python is crap for this. But that doesn't stop people from rushing to it with great delight and eagerness.

Something that can't be discounted is the degree to which people go to effort not because it's efficient and productive but because it's fun.

In the past, a power user was a person who knew how to use software really well and effectively, but didn't program. Now a power user is typically a person who knows how to use software really well and effectively but would rather spend all day trying to code rubbishy Python scripts.

Yes, what is it with Pythoners? I've just been trying to make sense of a StackOverflow q. "My use case is in converting some Python code to Haskell, I wanted to keep the API the same but add some type safety."

For crying out loud! Haskell is not just Python with 'type safety' sprinkled on top somehow. Neither is it a thing to convert Python code to language X and keep the same API. You're going to end up with non-idiomatic code in any other language.

Matt Parker on YouTube 'Stand Up Maths' does a heap of recreational maths, and presents really well. But always he 'proves' his claims with code in Python. Pleeeease use a language with more robust semantics and type disciplines. Publishing the code (which he does) doesn't really 'keep him honest', because I suspect most viewers won't bother crawling through it. He does massive amounts of importing datasets from public sources and 'crunching the numbers'.

(Also using a Higher Level Language would be more productive, less verbose, and therefore more fun/less tedious nitty-gritty -- but I suppose that's just my opinion.)

Yeah, but... but... PYTHON!!!1!!1!!

I think I've developed eyestrain from rolling my eyes at people who ask, in all seriousness, some form of, "When are we going to stop using Java and C# and whatever and move everything to Python because Python is obviously the best language ever?"

Quote from AntC on February 12, 2021, 1:45 am

Quote from Dave Voorhis on February 10, 2021, 10:03 am

Quote from AntC on February 10, 2021, 7:11 am

Quote from Dave Voorhis on February 9, 2021, 12:27 pm

Quote from dandl on February 9, 2021, 12:53 am

Quote from Dave Voorhis on February 8, 2021, 9:49 am

Quote from dandl on February 8, 2021, 5:07 am

 

A lot of end-user, technically-savvy-but-not-a-programmer types who would have used BASIC or dBase in the 1980s and VB and Access/Excel VBA in the 1990s / early 2000s have leapt onto Python like hungry beasts on steak. It hardly seems like the most efficient or effective way of doing things, but for the sort of people that do this sort of thing I suspect they're more motivated by the fun of being an end-user programmer than anything else.

Python is crap for this. Python is a fantastic glue language, largely due to the efforts of Mark Hammond (whom I know), but it's a code-first solution. Even Jupyter is really just an IDE for Python code. It's totally closed to people who just want to wrangle data and not write code.

Yes, Python is crap for this. But that doesn't stop people from rushing to it with great delight and eagerness.

Something that can't be discounted is the degree to which people go to effort not because it's efficient and productive but because it's fun.

In the past, a power user was a person who knew how to use software really well and effectively, but didn't program. Now a power user is typically a person who knows how to use software really well and effectively but would rather spend all day trying to code rubbishy Python scripts.

Yes, what is it with Pythoners? I've just been trying to make sense of a StackOverflow q. "My use case is in converting some Python code to Haskell, I wanted to keep the API the same but add some type safety."

For crying out loud! Haskell is not just Python with 'type safety' sprinkled on top somehow. Neither is it a thing to convert Python code to language X and keep the same API. You're going to end up with non-idiomatic code in any other language.

Matt Parker on YouTube 'Stand Up Maths' does a heap of recreational maths, and presents really well. But always he 'proves' his claims with code in Python. Pleeeease use a language with more robust semantics and type disciplines. Publishing the code (which he does) doesn't really 'keep him honest', because I suspect most viewers won't bother crawling through it. He does massive amounts of importing datasets from public sources and 'crunching the numbers'.

(Also using a Higher Level Language would be more productive, less verbose, and therefore more fun/less tedious nitty-gritty -- but I suppose that's just my opinion.)

Yeah, but... but... PYTHON!!!1!!1!!

I think I've developed eyestrain from rolling my eyes at people who ask, in all seriousness, some form of, "When are we going to stop using Java and C# and whatever and move everything to Python because Python is obviously the best language ever?"

Have to share today's gem from StackOverflow

I am new to binary search in Haskell. I have a python mindset, so that might be the reason I do it this weird way.

Response from a Haskeller asking

General notice: it makes no sense whatsoever to search a list this way, it'll actually be much slower than a simple exhaustive search.

(Looks like the pythonista had tried to adapt a binary chop search over an array; including destructive assignment to the trailing index; then merely replaced a python loop with Haskell recursion.)

There are umpteen tutorials and SO answers explaining why lists are not arrays; and advising all sorts of better data structures if you're needing to search often.

Would you mind a few extra eye-rolls for me, you seem to be better practiced.