Slashdot Mirror

← Back to Stories (view on slashdot.org)

'Picat' Programming Language Creators Surprised With A $10,000 Prize (bcexcelsior.com)

Posted by EditorDavid on from the you-may-have-already-won dept.

An anonymous reader writes: "I didn't even know they gave out prizes," said a Brooklyn College CS professor, remembering how he'd learned that a demo of the Picat programming language won a $10,000 grand prize last month at the NYC Media Lab Summit. Professor Neng-Fa Zhou created Picat with programmer Jonathan Fruhman, and along with graduate student Jie Mei they'd created a demo titled "The Picat Language and its Application to Games and AI Problems" to showcase the language's ability to solve combinatorial search problems, "including a common interface with CP, SAT, and MIP solvers."

Mie tells the Brooklyn College newspaper that Picat "is a multi-paradigm programming language aimed for general-purpose applications, which means theoretically it can be used for everything in life," and Zhou says he wants to continue making the language more useful in a variety of settings. "I want this to be successful, but not only academically... When you build something, you want people to use it. And this language has become a sensation in our community; other people have started using it."

41 of 63 comments (clear)

  1. Picard language by Anonymous Coward · · Score: 5, Funny

    Computer, make it so!

    1. Re: Picard language by CanadianMacFan · · Score: 1

      Just make sure that you have 5 years of experience because that's what all of the recruiters will be asking for.

    2. Re: Picard language by Tablizer · · Score: 1

      That's why I invented Lie++

      --
      Table-ized A.I.
    3. Re: Picard language by rholtzjr · · Score: 1

      Yea, I remember that quite a few Job descriptions back in 1999 that you needed 5 years of Java experience for positions. I was always baffled at that as in order for that to be accomplished you would have had to been on the original development team of the language as 1.0 was not released until 1996. And even then there were JDBC memory leaks in 1.0.18 in the Kiva Server.

    4. Re: Picard language by BlytheBowman · · Score: 1

      This is done to exploit a loophole so companies can say "SEE! SEE! We can't find an American willing to do the work, so that's why we need to outsource/bring in a H-1B worker!". Sometimes you end up seeing obvbiously impossible requirements such as "10 years experience in Microsoft Office 2012" and other such shit, but the people who are supposed to "protect" American workers are either criminaly stupid, taking bribes to look the other way, or both. Employers could put "must be able to train and ride magic pink unicorns to deliver leprechaun shit door to door" as a requirement and get away with it. The whole fucking system is a cruel joke and you are all being laughed at behind closed doors by these fuckers

    5. Re: Picard language by Anonymous Coward · · Score: 1

      Employers will always want more bang for their buck, they will always aim high for a candidate meanwhile competition domestically and globally will always work against the employee. Either we all join a Union or compete directly with these honchos, but who has that kind of money?

    6. Re: Picard language by Half-pint+HAL · · Score: 1

      Just make sure that you have 5 years of experience because that's what all of the recruiters will be asking for.

      That's why I invented Lie++

      If you've got zero years experience, you'll need to invent Lie++++++++++

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    7. Re:Picard language by tigersha · · Score: 1

      https://www.youtube.com/watch?...

      --
      The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
    8. Re: Picard language by Diss+Champ · · Score: 1

      Don't you mean ++++++++++Lie

    9. Re: Picard language by Half-pint+HAL · · Score: 1

      Damn. 20 years of programming and I'm still making the same bugs!

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
  2. Using multiple languages by bigbang137 · · Score: 2

    In a proper microservices world, there is indeed room for unpopular languages. To be a citizen of this world, at minimum they merely need to have IPC message passing support. This means REST, WebSocket, RPC, pubsub, etc. Giving individual developers the freedom to work with their language of choice for each subproject is immensely rewarding and powerful.

    1. Re:Using multiple languages by Dutch+Gun · · Score: 1

      Yep, I agree, although I think "microservices" is better described as "any sort of specialized language domain", and is a little less buzzword-bingo-ready.

      I recently finished work on a small embedded language that I'm using in my own projects. I published it on GitHub. Interest? Zero. Quite literally, no one else is using it, as far as I can tell. No worries, it's got one satisfied customer, and it's available for others to use if they want. It was hugely satisfying to design the language and work through a bunch of problems in the design and implementation phase. I spent quite a bit of time on API documentation and even a comprehensive tutorial, so if anyone ever stumbles across it, it shouldn't be too hard to pick up.

      I think it's a great thing to keep designing new languages, even if very few of them gain traction. At the very worst, it's likely that they'll inspire interesting changes and trends among the bigger languages in their next revision. At best, a few of them may catch hold and grow into something cool. I think every programmer at some point thinks "what would I do differently if I designed a language from scratch?", and a few of them even go try it out.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    2. Re:Using multiple languages by bigbang137 · · Score: 1

      Sure, I meant the language should have good APIs to the OS IPC features for interacting with other processes, whether the processes are local to container, local to host, or remote. For webapps, yes, the language must support the commonly used communication features, mainly asynchronous ones.

    3. Re:Using multiple languages by psergiu · · Score: 1

      Link please.

      --
      1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
  3. Comparison with Prolog by bigbang137 · · Score: 2

    > Compared with Prolog, Picat is arguably more expressive and scalable: it is not rare to find problems for which Picat requires an order of magnitude fewer lines of code to describe than Prolog and Picat can be significantly faster than Prolog because pattern-matching facilitates indexing of rules. Ref: http://picat-lang.org/

  4. standards by Anonymous Coward · · Score: 1

    And this language has become a sensation in our community; other people have started using it.

    That's a pretty low bar for 'sensation'

  5. Latency between services by bigbang137 · · Score: 1

    Old schoolers will inevitably complain about high latency between microservices. If this strongly matters, there are InfiniBand and PCIe fabrics for very low latency.

    1. Re:Latency between services by Anonymous Coward · · Score: 1

      Old schoolers will inevitably complain about high latency between microservices. If this strongly matters, there are InfiniBand and PCIe fabrics for very low latency.

      Service oriented has its place. I just get tired of it being branded as the cure all for everything. I've actually spent a lot of time working towards low latency near real time solutions, and now we have people wanting to push SOA everywhere, and to a large extent dismissing any latency or performance concerns as me just being an idiot or something. Sometimes all the extra layers do matter, and sometimes it just isn't worth the problems created for the problems solved. Of course a problem doesn't have to be all SOA or all conventional design. Modularity can occur a variety of ways. That being said, json is becoming a new best friend. Creating interop layers where configuration time stuff is passed in a way that doesn't continually require API changes is nice, and well everyone speaks json, one way or another... Text is fine for stuff you do once at startup, usually, and when it is not you can pass along structured binary data. It doesn't have to be all one or all the other. Most API calls are too simple to warrant even a json string, though in future I think I'll move towards fewer, more customizable functions. The key is however, to not have the runtime stuff that requires low latency slammed through a bunch of layers and/or conversions. Shared memory, like it or not, is still king for true low latency work, even if it is problematic in other ways. I think last time I checked I could run around 2000 independent threads that only read/write shared memory and do it all lock free with no problem. Now at that point your hitting the limit on your PCs ability to handle threads, but the scaling still works. Add a thread pool and who knows the limit, though I seldom need enough to justify the pool. Try doing that with a couple thousand separate executables? It likely won't end well. At minimum latency is likely to go right out the door with all those extra layers and bookkeeping. Most likely performance as well.

  6. exageration much? by JustNiz · · Score: 2

    > theoretically it can be used for everything in life,

    VM? garbage collector? no pointers? I'm not seeing anyone writing OS's, device drivers or any other low-level stuff in this anytime soon.

    1. Re: exageration much? by rubycodez · · Score: 2

      but this language can't even theoretically be used for everything; you can't write an OS kernel using it

    2. Re:exageration much? by Half-pint+HAL · · Score: 3, Interesting

      "... Picat "is a multi-paradigm programming language aimed for general-purpose applications, which means theoretically it can be used for everything in life," ..."

      They better hurry. Perl is way ahead on the multi-paradigm thing.

      Multi-paradigm will always kill readability until we accept that sequential plain-text files are unnecessarily limiting.

      In programming, we're taught to keep lines short for readability, as something like "[i]x = ((i+j/a)+(x+5)/4*sin(s^x/4)/3)*2/6)+34[/i]" is so difficult to read that I can't be sure I've matched my parentheses without counting, and I can't tell what the calculation does. But if those divisions were rendered on-screen in the international standard mathematical way of placing the dividend over the divisor with a line in between (like the way vulgar fractions are presented) and the exponentiation was rendered by formatting the exponent in superscript (as is also standard), the whole thing would be instantly visually understandable to anyone with a good level of high-school maths.

      You may not think that this has a lot to do with multi-paradigm, but maths itself is a paradigm (everything in computing could be achieved by direct manipulation of numbers -- it wouldn't be easy, but it would be possible) and it requires a rendering that is fundamentally different from flow control structures, for example.

      And flow control has specific rendering requirements too: cf. the argument between block delimiters and semantic whitespace. Semantic whitespace exists basically because if you have non-semantic whitespace, the language semantics may not match what the reader sees, if there is line indentation that doesn't match the blocks. So get rid of all the whitespace, and let the editor render the indentation on-screen in a way that makes the logical structure immediately apparent.

      Now imagine getting rid of "decorators" and just having a different font telling you clearly that you're looking at a different type of code. Suddenly we're free to start inlining SQL queries without a bunch of function call cruft and wrapping dynamically-created literal strings in procedures.

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    3. Re: exageration much? by dargaud · · Score: 1

      I'm a C programmer and I've written device drivers, but I need to ask: what makes a language suitable to write a kernel ? Once you have bit-level ability, ability to address the whole memory and inline assembly, that should be all you need, really. So why isn't there some kind of kernel, albeit experimental, in a very high level language ?

      --
      Non-Linux Penguins ?
    4. Re:exageration much? by zzarko · · Score: 1

      (everything in computing could be achieved by direct manipulation of numbers -- it wouldn't be easy, but it would be possible)

      Everything in digital computing, on the CPU (machine code) level IS achieved by direct manipulation of (only) numbers. And I mean EVERYTHING.

    5. Re:exageration much? by Half-pint+HAL · · Score: 1

      What you need is a powerful IDE that renders the old fashioned sequential plain text source code in the way you describe. I see no reason why that couldn't be done.[snip]

      And there are good reasons to stick to plain text for source code. There are people who are more productive using powerful text editors such as vim than using heavy IDEs.

      The reason they're more productive in plaintext is A) because the language is designed for plaintext, and B) they know the source code. The productivity problems really come in when you're dealing with code maintenance, which is a lot of the code lifecycle -- hell, most of us average mortals struggle to maintain our own source.

      I have been in emergency situations where source code urgently needed to be fixed while the workstations with fancy IDEs weren't available due to other problems occurring simultaneously but a plain text editor and other basic tools were. When you have to get things done with more basic tools than you normally use it's important those tools can handle your code.

      But if the IDE is the language, surely you would have the IDE on any machine using the language...?

      And don't forget search tools, diff tools, merge tools, SCMs, etc. There are loads of useful and essential programs that work best with plain text. The simplicity of plain text has huge benefits.

      What you're talking about is presentation. Keep that separate from the core, just like you keep your presentation layer separate from the domain logic in applications. In other words, implement your presentation requirements in your IDE and don't make the mistake of thinking that won't be able to handle plain text source code in a powerful way, otherwise you're likely to create more problems than you solve.

      OK, I don't suppose there's any harm in the source code having a plaintext representation.

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    6. Re: exageration much? by JustNiz · · Score: 1

      Basically efficiency/performance and controllability of timing. Despite that many people would argue Java is as fast as C, it really isn't, so a kernel written in Java or any other high level language would be relatively slow and bloated (i.e. a memory hog).

      Functionally, I dont see that inline assembly is an absolute necessity, but accessing memory mapped hardware and stuff like DMA registers would be, so you at least need pointers and to be able to dereference them.

    7. Re: exageration much? by JustNiz · · Score: 1

      PS: My statement about inline assembly not being necessary presumes you have a bootloader that intiailizes hardware, sets up stuff like ISRs and bootstraps the kernel. I'll never say anythings impossible but that would be a real challenge therefore stupid to choose to write in a high level language.

    8. Re:exageration much? by Half-pint+HAL · · Score: 1

      Like your word processor is the English language, you mean? Like the hammer is the nail? You seem to have trouble with separation of concerns.

      That's an invalid comparison. Computer programming languages are designed exclusively for the communication of instructions from a human to a computer. You can (if you want) write a piece of code on a bit of paper, but the main purpose of doing so (outside of the classroom) is to later input it into a computer so that the computer will do something. It's not for communication between humans, and the computer doesn't write responses to the programmer in the same language.

      So we have something that is designed for communicating instructions to a computer, that is almost always authored in a computer-mediated environment. It seems a bit silly that the computer isn't interpreting the code as it is entered, and everything is delayed until the programmer hits "compile" (or just "enter" in REPL environment).

      And then we build these IDEs that do syntax highlighting, parenthesis matching and block hiding/folding for us, and they're reinterpreting the code using a parse that may or may not match the language compiler/interpreter itself. It lets us make loads of silly little mistakes because it doesn't know enough about the language to spot when we've made a mistake.

      So the IDEs get more sophisticated, and start trying to interpret scope and suggest valid identifiers when we start typing, but we still can't be 100% sure the computer isn't confusing two different things.

      All this is because we have two separate mediations by the computer, programmed by different teams, instead of one; all this is because the IDE isn't the language. What I'm proposing is a language where the IDE is the language, but not a half-hearted attempt like Scratch which slows you down by taking your hands off the keyboard. Not one that restricts your choices to a screenful of drag-and-drop elements. One that gives you all the elements of the richest, most powerful languages used in professional and academic circles, but lays them out clearly and unambiguously, instead of hiding the semantics in an obscure string of #@! declarations.

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    9. Re:exageration much? by Half-pint+HAL · · Score: 1

      err... what? Split your code into multiple source files and open each one in a different colored emacs. Why does everything have to be so complicated?

      Cross-calling is one of the nastiest things you can do in terms of efficiency, as all variables have to be checked as being valid in the callee environment. Strings are difficult enough, but arrays and lists vary dramatically between languages in their internal implementations. This is why people hardly ever cross-call (and when they do, it's typically to C, where they've coded up direct representations of all the required datatypes from the host language.)

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    10. Re:exageration much? by colinwb · · Score: 1

      "if ... the exponentiation was rendered by formatting the exponent in superscript"
      In the 1980s I was working in insurance, specifically actuarial work which for historical reasons has many functions written with subscripts and superscripts. I considered, but didn't try implementing, a language which used up to three lines for a statement: a middle line for the basic statement, an optional lower line for subscripts, and an optional upper line for superscripts.
      Recently, quite by chance, I discovered that a 1970s language HAL/S, designed for the Space Shuttle, had actually implemented that.

  7. Re:OpenSSL got like ~$2000 dollars a year by Anonymous Coward · · Score: 1

    These Markov chain spam generators are getting better all the time!

  8. Re:Captain Sidies language by Hognoxious · · Score: 1

    # It's better to burn out than it is to rust...

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  9. gross. by Gravis+Zero · · Score: 2

    Picat looks like what you get after Python eats Javascript and then vomits. I give it s/[stars]/1 star.

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:gross. by Anonymous Coward · · Score: 1

      you forgot to end each sentence in a comma,

    2. Re:gross. by Capsaicin · · Score: 2

      Picat looks like what you get after Python eats Javascript and then vomits.

      Looks a lot more like Prolog which has swallowed an OO-flavour of Pascal actually.

      --
      Better to be despised for too anxious apprehensions, than ruined by too confident a security. --Edmund Burke
    3. Re:gross. by bigbang137 · · Score: 1

      Either way it is puke-worthy. Redundant characters in code make my blood boil. Python and Nim almost got it right. But Picat had to pickaxe those lessons.

  10. Re:Wikipedia fail! by TheRealMindChild · · Score: 1

    Wikipedia deletes shit they deem "no one cares about"

    --

    "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
  11. Lock-free writes by bigbang137 · · Score: 1

    Lock-free shared-memory writes seems like a black art. Don't know how it works or how you did it.

    1. Re:Lock-free writes by GerryGilmore · · Score: 1

      The one example that I've seen basically uses shared memory as an expandable pool of fixed-size elements (structs), using an enum to control the size. The real trick is to structure the thing so that one-and-only-one thread/process controls the writing, whereas many others can read with abandon. Those readers could send messages through a separate channel to request a status change, but they didn't directly write to shmem. I'm not aware of any method to handle true multiple shmem write access without some form of locking, though....

    2. Re:Lock-free writes by Anonymous Coward · · Score: 1

      The one example that I've seen basically uses shared memory as an expandable pool of fixed-size elements (structs), using an enum to control the size. The real trick is to structure the thing so that one-and-only-one thread/process controls the writing, whereas many others can read with abandon. Those readers could send messages through a separate channel to request a status change, but they didn't directly write to shmem. I'm not aware of any method to handle true multiple shmem write access without some form of locking, though....

      The one producer many consumer model works well with it. If you assume the producer and the consumer are disconnected, where the consumer _must_ keep up, or simply drop data, then you can do it just with basically a 64 bit integer that keeps track of the points added. The consumers each look at that integer and do a mod operation on it to find the real data in memory, as well as checks for likely data loss. (The consumer should not read a point that may be in the process of being written.) The consumer must of course keep track of its own position, but the producer doesn't need to know it, since it isn't going to wait anyway.

      This kind of thing can be truly lossless and provably so with an RTOS, assuming the producer and consumer are simple enough that you can prove it all runs in time.

      Multiple producer to Multiple consumers for one queue is well obviously harder, but there _is_ an easy way. First create the simple producer/consumer queues that are lock free for all the producers. Second and last, create an independent thread that gathers data from all those queues and puts them into a final queue, while of course watching to make sure it is keeping up. Basically your adding another layer to avoid the locks.. Of course the easy way makes little sense unless you needed the data in all those smaller queues in the first place... Locking with perhaps a bit of buffering to reduce the frequency is likely better...

      Now if only I could find a way for windows to reliable sleep for say a tenth of a ms, and only a tenth of a ms... Heck, I'd settle for reliably sleeping for 2ms. It would be an improvement. You can set the clock to .5ms, but sleep will be at minimum 1ms and I think can extend to 15ms or so. I've thought about using a thread pool or similar and then spinlocks maybe, but the complexity isn't very attractive. Still, if you wrote out a schedule for everything to run, and used spinlocks, you might be able to get sub ms accuracy in windows, most of the time, at the expense of tying up one or more cores... There are other timers, but few scale in threading that the ordinary sleep call.

  12. Re: OpenSSL got like ~$2000 dollars a year by BlytheBowman · · Score: 1

    Woah, this is the worst case of VD I have seen in a long time! (VD = verbal diarreah) Veee Deee, it's for everybody....

  13. Re:Wikipedia fail! by rubycodez · · Score: 1

    wikipedia deletes knowledge that has little reference on the net, the kids running it don't realize most human knowledge isn't on the net