Guess the author thinks Confucianism is bullshit (fart). I APPROVE!

The sample image of the first feature is Confucianism surrounded by the fart character. The feature highlight only one found entry per line. That is what you get when you search for fart.

Most of newly graduates of any subject don't know much about real world jobs. You are just one of many, but you care to ask about this on HN, that's something.

And a warm welcome to this imposter syndrome help group, we are always afraid of missing out on some tech. Accept it, everyone is missing out on most of the tech.

When I was studying CS in college, I always wondered why the classes don't teach us about the hot Windows programming thing. All we did were tiny console C programs. I realized that very late, CS classes are meant to let you know about the fundamentals. You probably won't use these skills directly at work, but you will have ideas about how the languages and systems work internally. That pays in the long run.

Just go explore and make mistakes, you will be alright.

> All we did were tiny console C programs. I realized that very late, CS classes are meant to let you know about the fundamentals. You probably won't use these skills directly at work, but you will have ideas about how the languages and systems work internally. That pays in the long run.

At one point you realize, when you remove all the boilerplate, every piece of software is fundamentally just a "tiny console C program". All IPC and networking is isomorphic to reading stuff from stdin and writing to stdout. And when you ignore IPC, all you're left with is just pure algorithms.

Leetcode (and the likes) always made sense to me. It's measuring how well you can solve the fundamental problems, not how well you can fill out vendor-specific bureaucratic forms.

I think that you're missing the linking element of software units. It can be very intimidating, particularly from an outside view.

I have been writing C for years and I can tell you in a second if you are accidentally dereffing the stack or not doing a bounds check. Yet, I still barely know my way around CMake! It's daunting, and I haven't worked on any enterprise scale C projects, hence I have no reason to learn how to properly separate, and later integrate, my software components.

I agree, but even modularity is just an implementation detail, rising from the finiteness of human work capacity and computer resources. Algorithmic solution to the problem is the same, whether it is implemented in a single implementation-specific C file or a cross-platform multi-repo project. Also, it is (IMHO) much easier to learn engineering principles, than how to solve algorithmic problems. The latter is akin to solving mathematical problems, which require finding a problem-specific needle of knowledge in the haystack of mathematics.

I still write console programs all the time. But I haven't programmed for Windows in over a decade.

It's also helpful to realize that you "stand on the shoulders of giants".

Funny, I think the walrus operator makes code cleaner and easier to understand.

Many of my code were like this:

    foo = one_or_none()
    if foo:
        do_stuff(foo)

Now I have the following:

    if foo := one_or_none():
        do_stuff(foo)

This kind of code happens quite frequently, looks nicer with walrus operator to me.

I haven't yet fully adjusted to the walrus operator, but to me the choice would depend on what happens _after_ the "if" statement.

In both cases, "foo" continues to exist after the "if" even though the second example makes it look like "foo" is scoped to the "if".

So to my eye, the following would look super weird (assume do_more_stuff can take None):

    if foo := one_or_none():
        do_stuff(foo)
    do_more_stuff(foo)

whereas the following would look fine:

    foo = one_or_none()
    if foo:
        do_stuff(foo)
    do_more_stuff(foo)

Honestly, for this specific case, I prefer one_or_none() to return an iterable with zero or one items, and then just doing:

  for foo in one_or_none():
    do_stuff(foo)

If you don't control one_or_none, but it returns an Optional, you can wrap it with something like:

  def optional_to_tuple(opt_val: Optional[T]) -> Tuple[]|Tuple[T]:
    return (opt_val,) if opt_val is not None else ()

Would have been more Pythonic as:

    if one_or_none() as foo:
        do_stuff(foo)

I didn't recognize this use of "as" as valid Python, but tried it in 3.9 just to be sure. Got a syntax error (as expected).

I am not fully up to speed with 3.10, but quickly checked the docs and it doesn't appear to have been added in 3.10 either.

Let me know if I'm missing something.

Oh, "would have" meaning python-dev chose a different spelling. Not, as in it would-have been better if the example was written this way.

Oh, I see now. Thanks for the clarification.

Just curious, what are the advantages using w3m instead of eww?

One example: When I open this page here, in eww all comments have the same left margin and I have no idea what is a reply to what, but with emacs-w3m the nesting structure is visible.

Strange, I'm trying out standalone w3m right now and also don't get nesting. Maybe the emacs version is different. I'm guessing HN must indent with CSS (which w3m pointed out it does not attempt to support) even though the comments are in a table.

Actually, HN indents with a spacer gif, in true early 00's fashion :)

  <img src="s.gif" height="1" width="66">

hah, I love it.

I am kind of glad there are so many folks on hacker news using Firefox.

I "fixed" it by refreshing Firefox. You can refresh Firefox from [Help] menu item, and choose [Trouble shooting Mode...]

All features and principles aside, it's a different code base. A mono culture is dangerous for the system, remember heartbleed?

Are the families, friends and supporters of Snowden constantly harassed or threatened by the US government?

I know the project is probably for some fun. Since you already have a sample lisp code to test, why not write tests for it.

Are you suggesting click-bait headlines are equivalent to out right disinformation?

Certainly not "equivalent", but they are indeed a form of disinformation.

I used to love ORM, I used it everywhere. Writing another language in the language I am coding is wrong. ORM simplifies my programs.

No, ORM does not simplify coding! It's a big complex adapter which does not fit many cases.

RDBM itself is complex enough, let's put another complex abstraction above it so we can forget about the tables and columns and joins and foreign keys. Complexity added upon another complexity does not make a polished interface.

If you want to use ORM, you have to learn both SQL and ORM with some depth at least. When problems occur, you have to debug both.

20 years in, I am still learning about RDBM. I still hate to compose SQL in code, but there is no better way.

Databases are used in every situation. Want to store data? Database. Want to communicate between processes? Database. Want to store logs? Database. There are different solutions for different scenarios, but as long as the DB chugs along, why? Sometimes it's sickening.

So 20 years in, the ROI of learning SQL is great. Please don't avoid learning about RDBM by using an ORM. Just learn it.

Actually, I'm not without ORM now a days. Light-weight ORM like Dapper serves well, it does not abstract out the concepts of RDBM, but make things easier.

> Writing another language in the language I am coding is wrong

That's not what's wrong. But rather writing in some language within a string literal is what feels wrong to you.

With better integration it'd be natural. The problem is, of course, there's no single SQL dialect.

" I still hate to compose SQL in code, but there is no better way."

The one big problem with SQL is intermixing query language and query parameters. This requires escaping and is the source of many PHP vulnerabilities. Instead of

    do_sql('SELECT * FROM tab WHERE name = "abc"')

there should have been a standard where you wrote

    do_sql('SELECT * FROM tab where name = V1", "abc")

or something like that. So you don't do string operations on the query parameters.

Aren’t you referring to parameterized/prepared queries? Any proper DB driver/library should have this feature.

    do_sql('SELECT * FROM tab where name = ?", "abc")

https://www.php.net/manual/en/pdo.prepared-statements.php

I recall getting curious when I was younger where the deranged advice of “sanitize your queries” came from — realizing that you should be able to simply tell the database that this is a string, not part of the query itself. SQL injection should barely exist as a concept, let alone be the #1 web vulnerability.

IIRC it turned out MySQL supported parameterized queries for ages, but the stdlib php MySQL library just didn’t add support for it. This discovery solidified my understanding that PHP has been giving developers brain damage for decades.

Unless you're using hardcoded values, using bind variables is the only proper way. Otherwise, the DBMS has difficulty recognizing the same query pattern for performance, and you're open to injection vulnerabilities for security.

https://www.databasestar.com/sql-bind-variables/

The big problem is the shitty workplace environment of today that discourages sharing, learning and proper software development.

A proper build-pipeline will include security scanners that detects these vulnerabilities automagically.

I don't know if it's a standard but both Postgres and MySQL have PREPARE statements, and any sane language driver will implement it correctly

If you use IntelliJ IDE in their commercial version (at least of PyCharm) they integrated DataGrip. Basically if you connect to your database and give an option to fetch your schema the IDE starts scanning for strings and if it detects SQL it provides IDE features to it as well (like auto completion, and some refactoring etc).

I think ORM and query builders were trying to hack around to make IDEs understand SQL, when in reality this approach is what actually was needed.

No, ORM provides an inspectable central entry point for your models with a standardized API. That's the feature.

That's why you get a great django ecosystem: the ORM abstractions allow all libs to rely on the fact the rest of the code access the model the same way.

The issue is that if you try to squeeze a relational model into object oriented model you won't get an efficient solution.

Solutions like django might be good when you're starting the project or it is something very simple, otherwise you'll have to fight with it to get something done more efficiently.

My point is that using plain SQL (I personally prefer asyncpg as it provides interface matching postgresql) is actually also easy. Especially if you have IDE that supports it.

I also realized that with this approach I rarely need to even transform the data in any way. Usually whatever I want to do I can get in a single SQL statement (even for things that have some hierarchy, thanks to aggregation functionality). So in the end the function just gets data and displays it.

Sure if you don't need to build an ecosystem, don't need introspection and can forgo integration, sql is indeed easy.

Also, SQLA proves that an ORM doesn't have to prevent you from getting an efficient solution, you just have to offer several layers of granularity.

Eventually, it's not an or proposition. In django you do use raw sql when you need so. but your auth system doesn't, and a plugin will solve it for you.

One nifty use-case for ORMs is decoupling the logic from the data.

I can prototype in Python/SQLAlchemy/SQLite and deploy to Python/SQLalchemy/PostGreSQL via a pipeline with confidence that I'm actually managing the complexity.

Cracking open some legacy code with vast swaths of embedded SQL is a source of much weeping and gnashing of teeth when the time comes for maintenance.

I did this for the longest time, testing with SQLite and running with PostgreSQL, until I discovered that this was completely unnecessary extra complexity. It turns out that setting up and starting a fresh PostgreSQL database takes about one second, so it's just as easy to just spawn a Postgres for the unit tests. And now I get to enjoy some immensely useful Postgres-specific SQL syntax like "FOR UPDATE SKIP LOCKED".

> Writing another language in the language I am coding is wrong.

Yeah but you're writing your strings in english anyway.