But in its current state I don't think it actually replaces any of CodeQL's use cases. The most straight forward way to do what CodeQL does today, would to be implement a flow analysis IR (say CFG+CallGraph) on top of tree-sitter.
Thanks for the feedback. That's the exact plan :raised_hands:
current state of codepathfinder is less than 5% of what codeql has implemented. As security engineer, I personally use it and i'll keep adding + closing the gap.
Feel free to contribute ideas/feedback/bugs. Super appreciable honestly!
Flow analysis, especially propagation, is a hard problem to solve in the general case. IMO, the one tool that had the best, if language-specific, approach was Pyre – Facebook's type checker and static analyzer for Python.
Countless people before me have tried, and I myself have written and maintained a (proprietary) JS toolchain that has caused a some trouble with users over the years.
In the end, using a systems language is what I've settled on.
> Further, you double the dependencies
I'm acutely aware of this problem.
Which is why if you look at Jam now, it has zero dependencies. Not even libc (which is mostly thanks to Zig).
The only "dependency" is a Unicode property detection library I wrote for Jam itself. And it is currently the fastest implementation for Unicode identifiers to exist.
This simply isn't possible in JavaScript.
Same story with the Parser, etc.
Parsers for JS already exist, but it's already known how far one can go, stitching together existing tools that aren't meant to work with each other.
Some dependencies can't be avoided in the long run,
But I try to be very cautious, and vet every dependency thoroughly before considering it an option.
Ultimately, the dependence on two languages is a tradeoff that I've accepted, and the problem you mentioned with dev environments is one I'm going have to live with.
> which is as performant than using mutable array.
I get what you're trying to say, but that is provably false.
As great as the OCaml compiler is, it currently is not capable of the aggressive optimizations that GHC can do with lists.
More often than not, the compiler mostly won't have enough static assertions to reliably generate machine code like that in a real world application (unless explicit mutation is used, of course).
> Functional programmers just trust that their compiler will properly optimize their code.
Precisely.
This is why having safe local mutation as a language level feature can give more control to the programmer.
We no longer have to rely on the compiler to correctly guess whether a routine is better expressed as an array or a cons list.
> The whole article is secretly about Haskell.
and ML, Koka, Clean, Mercury.
The article is about allowing local mutation without breaking referential transparency at the language level.
"Stop using haskell" is a very shallow conclusion, IMO.
They have changed both the title and the article since it was posted... almost certainly due to comments like these which used to be at the top. Though editing titles should be impossible imo. Editing comments is fine, but if you screw up titles you should be forced to resubmit and not be able to rug-pull an entire discussion.
Qt licensing is its own mess.
For commercial software, the pricing is 350-500$ per developer, per month. Seriously [1]. The company that now owns the framework doesn't seem to acknowledge the gap between big enterprises and solo developers/smaller teams.
[1] Yes, one can use Qt for commercial software without buying a license (as long as it is dynamically linked), but their marketing does everything it can to hide that fact. Also, the newer additions to Qt do not fall in this category – for those, you have to pay.
- Go LGPL. Sure, you will need to ship binaries and libs, but there are tools within the SDK that do this automatically for you (windeployqt, macdeployqt, etc.). And as others have stated, it is a problem that was solved years ago.
- Go Commercial to link statically. If you are a single developer, there is an annual license available for $499 (up to $100k yearly revenue).
It always shocks me developers complain so much about QT licensing. For any other business, an expense that small for so much value seems trivial. Without a decent UI software is a terrible for experience for most users.
The fee is for selling someone else's software. I personally despise capitalism, but your complaint about it is among the least convincing ones I have ever heard.
That is 4,200-6,000 $/yr. In the US, a junior developer in a software company costs (all-inclusive, not just salary) around 150,000-200,000 $/yr. That is 2-4% of yearly cost on tooling. That is not very much.
It might not be worth the price, but that is hardly ridiculous. It is quite believable to get a 4% productivity improvement from appropriate tooling. You need to do a cost-benefit analysis to determine the answer to that question.
Lol scrolling on qt is worse than on the web. I mean, you can use normal scrolling super easily on both (you don't have to do anything, and it just works). But truly custom scrolling is much harder on qt than web. In a way that's a good thing, but again, the default is just as easy on the web as it is on QT. Plus you don't have to deal with the qtquick/qtwidgets/etc thing and the non open source parts of qt
That's why I said it might be a good thing. My main point was that it's just as easy on the web for standard scrolling. But even if you don't want standard scroll behavior, it's still easier. There's nothing easier to do on qt than on web. Compare a qtgraphicsview or qt3dcanvas to a webgl canvas and again, it's fighting against the framework versus stuff just working. Now sure qt is much better for tons of other stuff, but I just found it weird that the comment I was replying to mentioned wasting time on customizing stuff as being the downside of web apps, as if it's not a much more difficult task to do in qt.
You remind me when microsoft was claiming that bash was hard and as example did some crazy obfuscated bash scripts, rather than just doing them the sane way.
If you're doing a GUI, you have no reason to be doing canvas manually.
What? Even with QT you often have to use a painter and draw what you want more or less. You also need a canvas to display anything that is visualisation related. In any case it doesn't matter, as I said, scrolling is just as easy on the web as it is on QT. my point was more general, if you want to do anything custom it's easier to do in JS than with QT. Even using the multiple tools QT offers to customize the view (the painters, canvases, 3d widgets, etc)
You're just showing me you've never dune as much as an hello world using QT. Which is completely fine, but don't paint yourself as knowing what you're talking about.
I like how the comments in Devin's HN thread were all bleak and full of doom.
But now that it's a different industry AI is eating up, we're congratuling the team and sharing generated songs.
This looks like a fun tool, but when the smaller artists in Udio's training set recorded their albums, they didn't price in a capitalist company using their work to put them out of business.
Overall, I see this as a legacy problem, with new developments in AI acting as a positive catalyst to drive robust and clarified legislation around music royalties and copyright - badly needed since the quagmire the Robin Thicke 'Blurred Lines' judgement caused.
“At the core of music is math, and every mathematical combination has already occurred in some way, shape, or form. It’s the performance of that math that changes depending on the singer or the song style...Saying something is derivative is a pretty hard argument for copyright owners to make because we all borrow ideas from things that we’ve heard before. AI just does it at a way faster speed.”
Interesting points.
This isn't just about music, though.
Udio can do standup skits too, and elevenlabs can already replace NPC dialogue voice actors in games and audiobook narrators. Smaller music producers who make intros for big youtubers, or sound designers who make tunes like notification sounds and SFX for video game screens are going to have their lives severely impacted by AI audio generators.
Broadly we're in agreement - I just see the examples you use as raising the bar of production values of the low-end commercial use-cases, rather than subjugating the industry outright.
Take for example the Wordpress Blog 'Review Site' ecosystem. The ubiquity of low-quality and keyword/SEO optimised Wordpress based review blogs for e.g. Dropshipped Mattresses didn't destroy the blogging industry - in fact it was the exact time sites dedicated to long-form content started emerging like Medium.
More pertinently, you cite the example of the intro 'stings' for youtubers - these were once strictly the purview of SFX Houses, but innovations like Adobe After Effects and Final Cut Pro's cost and licensing models democratised the industry to the extent where we now expect broadcast-TV quality fades and transitions in basic family home videos. This didn't negatively impact the high-end of the market so much as lower the barriers for entry for the indies in a way not seen since the advent of Super-8, and later Digital, Video Recording.
Simply put, if there's low-hanging fruit to automate in the nuts and bolts of media production, history tells us it will eventually be automated to the strength rather than the detriment of the industry. From Da Vinci to Warhol, from Picasso to Hirst, there has always been a cross-pollination between industry and art. More to the point, there has always been subsequent re-evaluation of what constitutes Art following these techno-cultural upheavals.
We saw it in the 1980s with particular relevance when Art was enhanced, not degraded, by the opportunities afforded by the audio and video sampling revolution of the time.
The postmodernist approaches to music that emerged as a result of sampling were, at the time, decried as the end of both musicianship and creativity by many critics and authorities. 40 years on, Academics have re-evaluated and rightly see it simply as the natural and due evolution of Western Musicology from the Musique Concrète of the 1940s.
Where AI differs from the historical examples to date is in its ability to represent concept and context, to effect subtext and nuance - ersatz or otherwise - in its output. To me this poses the real question that must be answered; namely 'How differently will this artistic paradigm shift impact us compared to every other one to date? Does the ability to render a visual concept in a distinct mode via articulation rather than ability detract from Art as a whole, or will it afford us greater opportunity in expanding the sphere of Art itself and remove any need to leverage artistic talent in the pursuit of gross commerce?'
But in its current state I don't think it actually replaces any of CodeQL's use cases. The most straight forward way to do what CodeQL does today, would to be implement a flow analysis IR (say CFG+CallGraph) on top of tree-sitter.
Even the QL grammar itself can be in tree-sitter.